On 24/02/12 11:19, Ron wrote:
In message<[email protected]>
Lee Noar<[email protected]> 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
first.
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
4.1.2.
Lee.
_______________________________________________
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
