[gccsdk] sfix doesn't work in all situations
beeb at woosh.co.nz
Fri Feb 24 03:19:11 PST 2012
In message <4F460D4A.1010906 at sky.com>
Lee Noar <leenoar at sky.com> wrote:
> I haven't tried this myself, but I think it's a case of:
> 1) Preventing the sfix variables from being created, ie, commenting them
> out in !GCC.!Run.
> 2) Translating all file names that have been suffix swapped back to Unix
> style, so h.header becomes header/h and o.object becomes object/o, etc.
> This suffix swapping is done in the create-gcckit script so commenting
> that out will prevent it from happening.
> Once the cross compiler is built, you can build the native compiler by
> make ronative
> and then
> to zip it all up for transfer to RISC OS.
Thanks, this does build a unix style layout for RISC OS.
Perhaps unrelated but gcc and friends aren't running properly with my
I went to my other linux partition and did a standard ./build-world,
make ronative, ./create-gcckit but still the resulting !GCC
errors with segmentation error.
Things I noted during the process of the above.
1. svn update svn://svn.riscos.info/gccsdk/trunk gccsdk
results in 'skipping file - at release xxxx' message.
But using 'svn update' does do a lot of file iterations before
finishing with the release number and looks like it is doing the
2. ./create-gcckit does not create a zipfile, or rather I couldn't
find one anywhere, so I used 'tar cf NewGCC.tar release-area'
When opening the archive with SparkFS there is a folder /of =Longlink
text files inside NewGCC.tar beside the release-area folder.
Actually NewGCC/tar././ and the lower level '/ 'folder has the
=Longlink files typically with
Could this be the same problem with paths that gcc and cc1 has?
gcc -mlibscl -O3 -o ackermann_scl ackermann.c
File '@' not found
Fatal signal received: Segmentation fault
Everything in the untar'd release-area folder appears OK,
I have tried both the 'full' and the 'kits" !GCC.
More information about the gcc