[gccsdk] sfix doesn't work in all situations

Lee Noar leenoar at sky.com
Fri Feb 24 09:01:25 PST 2012

On 24/02/12 11:19, Ron wrote:
> In message<4F460D4A.1010906 at sky.com>
>            Lee Noar<leenoar at sky.com>  wrote:
> <snip>
>> 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
>> doing:
>> make ronative
>> and then
>> ./create-gcckit
>> to zip it all up for transfer to RISC OS.
>> Lee.
> Thanks, this does build a unix style layout for RISC OS.
> Perhaps unrelated but gcc and friends aren't running properly with my
> native build.
> 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.

Are you perhaps mixing components from a 4.1.2 build with components 
from 4.6.3 (at trunk)? The shared libraries (and Shared Obect Manager 
module) are not compatible between the two, so make sure you only use 
components from which ever you are working with.

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

The pathnames you give below suggest that you are working with 4.1.2 and 
"svn update" will bring that source tree up to date with that branch, 
but above you seem to be trying to sync with trunk which is 4.6.3, so 
maybe it's skipping files that are too new for the current branch - 
that's just a guess though.

> 2. ./create-gcckit does not create a zipfile, or rather I couldn't
> find one anywhere,

Yes, sorry, that should have been:

./create-gcckit -pkg

to create the zips. You'll need to build native-zip in the autobuilder 

> 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
> release-area/kits/gccsdk-gcc-core-bin-4.1.2-Rel1dev/Examples/Module/ResourceFS/data/ThirdParty/GCCSDK_Example/
> Could this be the same problem with paths that gcc and cc1 has?
> 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 


More information about the gcc mailing list