In message <[email protected]> John Tytgat <[email protected]> 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. _______________________________________________ GCCSDK mailing list [email protected] Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
