[gccsdk] sfix doesn't work in all situations

Ron beeb at woosh.co.nz
Mon Feb 27 17:28:22 PST 2012


In message <f06a586852.Jo at hobbes.bass-software.com>
          John Tytgat <John.Tytgat at aaug.net> wrote:

> 
> 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.

That is effectively what I have had success with, using a helloworld/c
type directory system and sfix ="" for the binary line up in !Run.
It is then neccessary to use gcc helloworld/c (not helloworld.c)
otherwise you get "file not found", and it appeared to be working
that way OK. 
I realise we always will have to have the path translation of
$.foo.bar to /foo/bar and viceversa.
The tough part is removing the unwanted special directory suffixing
without upsetiing the wanted riscosification/unixification.

Slightly different story for a slightly different problem.
I have finally managed to produce the tar binary using the 
cross-compiler so that is free of directory sfixing by commenting out 
the feature sfix at line 128 in
~/gccsdk/gcc4/recipe/files/libunixlib/unix/features.c   

It possibly would be less intrusive to set at line 16

static const char __sfix_default[] ="";

Previous to this my tar binary needed  set unixenv$tar$sfix ""
every time it was used.(I previously reported the bug that the
riscosify control method doesn't work to disable suffix swapping)

Thanks   Ron M.




More information about the gcc mailing list