[gccsdk] sfix doesn't work in all situations
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:
>> 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
> 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
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:
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
> 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
This may be a symptom of using the shared library system from 4.6.3 with
More information about the gcc