In message <[email protected]> Ron <[email protected]> wrote:
> In message <[email protected]> > Lee Noar <[email protected]> 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 [email protected] ARM powered, RISC OS driven _______________________________________________ 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
