[gccsdk] sfix doesn't work in all situations

Ron beeb at woosh.co.nz
Mon Feb 27 15:30:54 PST 2012


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.

Ron M. 



 




More information about the gcc mailing list