[gccsdk] sfix doesn't work in all situations

John Tytgat John.Tytgat at aaug.net
Mon Feb 27 16:57:12 PST 2012


In message <5284506852.beeb at ron1954.woosh.co.nz>
          Ron <beeb at woosh.co.nz> wrote:

> In message <4F47C265.8060409 at sky.com>
>           Lee Noar <leenoar at sky.com> wrote:
> 
> > > ie
> > > gcc -mlibscl -O3 -o ackermann_scl ackermann.c
> > > File '@' not found
> > > Fatal signal received: Segmentation fault
> > 
> > This may be a symptom of using the shared library system from 4.6.3 with 
> > 4.1.2.
> > 
> > Lee.
> > 
> 
> Yes, I see that trunk has 4.6 which is different. You have to use
> trunk to get Autobuilder for 4.1.2 by the looks. I tried this and it
> works at the cross-compiler level. 
> But obviously there are changes for the RISC OS native !SharedLibs
> and unixlib.
> 
> For this Iyonix experiment, I had to use my previous downloaded r4.1.2
> binaries/!SharedLibs/Unixlib with the unix style file layout and
> the altered !GCC.!Run sfix"S.
> 
> gcc @.helloworld/c -o hw [-static]
> 
> Produces a elf[elf2aif] binaries that work but there is a loss of
> some concept of @ or the CWD somewhere by both gcc (note the need
> for gcc @.xxx/c) and the resulting binaries both have no concept
> of running from @ unless run from the CLI as @.hw or placed in
> the system path (Boot:Library) when they will run from the CLI
> as hw. Doubleclicking hw wont run them, just loads them into a
> editor.
> 
> I am interested in how this (un)sfixing has altered this CWD
> behaviour, also because the CWD relationship seems to vary a bit
> on some things I have ported in the past. I previously thought it
> was because not enough of the unixlib libraries were replacing
> the package's libraries.

I think you're confusing two different things concerning filename syntax
support in UnixLib.  First of all you have RISC OS vs Unix filename
specifications, e.g. $.foo.bar vs /foo/bar.

Secondly, you have the suffix swap support which is, as far as I can
remember, only applicable for Unix filename specifiactions when they
are converted to RISC OS by UnixLib to access the RISC OS file (or
visa versa when enumerating a RISC OS directory and its result passed
on the Unix dirent API).

I.e. a /foo/bar.c maps either to $.foo.c.bar or $.foo.bar/c on RISC OS (and
visa versa), where the former is with 'c' in sfix list, and the latter not.

In your gcc command line above, you are using RISC OS filename specification
so I don't think the sfix value is relevant in this case.  I believe GCC
really assumes to see Unix filename specifications (so it sees
"@.helloworld" as a directory and "c" as a file in that directory) so
IMHO it is by luck your example kinda works.

I believe if you really want to let GCC accept RISC OS filenames, specific
patches need to be made for GCC and you will probably loose its capability
to deal with Unix filenames.  Personally I don't think it is worthwhile
to persue such a feature.  Just use consequently Unix filename specifications
for GCC, your Makefiles etc. like foo.c or bar/foo.c.

I expect that if you remove c/h/o etc from gcc (and related programs) sfix
you can have the RISC OS filenames foo/c and bar.foo/c (instead of c.foo,
bar.c.foo) but I never have tried that.  Although I'm not really found
of c.foo style of RISC OS filenames, I don't see a point of forcing
developers to take another file hierarch approach of their sources then
they are used by the Norcroft compiler suite.  It doesn't make sense
to break compatibility as there is no gain.

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven




More information about the gcc mailing list