This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Lukas Ruf wrote: > > Unfortunately, it fails with the error messages I posted a couple of > days ago to crossgcc, see below. The reason why this happens -- I > assume -- is that the newly built ld.so is not executable (built for > target arm-linux as well, I think) > ( > ./build-arm-linux/glibc-2.2.2/elf/ld.so > ./build-arm-linux/glibc-2.2.2/elf/ld.so: Exec format error. Binary file > not executable. > ) > and thus the -- if not per default anyway -- /lib/ld.so from my default > development environment is taken. This ld.so is hosted on i686-linux > and is used for i686-linux targets only. > > Do you -- or does anyone else -- have any hint how I can solve this > issue? I updated my glibc-2.2.1 for arm-linux-gnu yesterday and there were almost no problems at all (if forgetting the disturbing 'mig' during the flight...) So it is hard to understand your problem... Ok, I had several working GCCs for arm-linux-gnu and two working glibc's (2.1.3 and 2.2.1 built by me) when starting, but I hadn't any problems when building glibc-2.1.3 earlier almost from scratch. I haven't followed what kind of advices you have got, whether they were right or wrong, but here are some experiences and opinions from me... Under Linux it is very easy to not start from scratch, so I probably just copied my native glibc-2.1.x headers and replaced the target dependent parts (in 'include/bits' etc.) with the arm-specific stuff from the glibc-2.1.3 sources (found easily with the "find . -type d -name arm" run in the glibc main dir). And then I got my bootstrap-compiler 'almost ok' in the first stage... I have never understood why using the 'cp' command to copy and the 'find' command to search things is so hard that the desperate choice of using the newlib-headers for the bootstrap-compiler has been recommended in some FAQs... My advice is to use the real headers stuff from glibc... So I expect your problem to be the 'GIGO'-effect, "Garbage-In, Garbage-Out". If you haven't a working 'arm-linux-gnu' target cross-compiler to compile glibc, what else can be expected than quite a lot problems? Using prebuilt stuff in the bootstrap-stage is one way to avoid problems... It is assumed that there are pre-built toolsets for 'arm-linux-gnu', downloadable from the net, and using them in the bootstrap-process helps a lot... One place is the Netwinder-site, 'http://www.netwinder.org', where one can find toolsets from 1999 (gcc-2.95.1 with glibc-2.1.2, 'http://www.netwinder.org/tools.htm') and up- to-date-tools too, from their 'AutoBuild' ('http://www.netwinder.org/build/glibc' and '.../gcc'). The 'egg' or 'chicken' (gcc or glibc) can be taken from there and used to get the own 'chicken' or 'egg'... But, as I wrote, getting somehow- working arm-linux-gnu headers for the bootstrap-GCC is possible too, and then getting somehow working libgcc.a's for 'arm-linux-gnu'... It should be self-evident that all Linux/x86-binaries will run ok on a Linux/x86 machine, but rumours say that they may not... Anyway the binaries working should be the normal case, so those Netwinder-GCCs should work on any reasonable glibc-2.x based Linux and using them as the bootstrap-GCC should succeed... Or to use one of their prebuilt glibc's and build all the GCC-parts on the first try using it... After building own GCC and own glibc, the Netwinder-stuff can perhaps be throwed away... Perhaps it is a shame for a real hacker to use prebuilt stuff, but using a prebuilt Linux-distribution, prebuilt native GCC, prebuilt utilities etc. is just a same kind of shame too... Another issue is the glibc-configure, here is my script for that: ------------------ clip ------------------------------------------- AR=/usr/local/arm-linux-gnu/ar \ AS=/usr/local/arm-linux-gnu/as \ CC=gcc-arm-linux \ CFLAGS=-Os \ LD=/usr/local/arm-linux-gnu/ld \ NM=/usr/local/arm-linux-gnu/nm \ RANLIB=/usr/local/arm-linux-gnu/ranlib \ AR_FOR_BUILD=ar \ CC_FOR_BUILD=gcc \ GCC_FOR_BUILD=gcc \ NM_FOR_BUILD=nm \ RANLIB_FOR_BUILD=ranlib \ ../configure --host=arm-linux-gnu --build=i586-linux-gnu \ --prefix=/usr/local/arm-linux-gnu --enable-add-ons=linuxthreads \ --with-headers=/usr/local/arm-linux-gnu/include ------------------ clip ------------------------------------------- All the 'build-your-own-cross-toolset-for-Linux/XYZ'-FAQs give quite the same structure for the command, but anyhow it is here again... (For instance see the 'www.penguinppc.org' Mini-FAQ for Linux/PPC-tools) The Linux-kernel-headers (asm, linux) were symlinked into the /usr/local/arm-linux-gnu/include from the kernel-sources of course... One self-evident? thing one can easily forget : What is missing from my script, is the selection of the specific ARM-CPU for which the glibc will be built... When building GCC, I used the default 'generic' or 'arm6' target because I only wanted it for 'something'. Browsing the 'gcc/config/arm/arm.h' and seeing the possibilities there helps to perhaps edit the '$build/gcc/tm.h' where the 'TARGET_CPU_DEFAULT TARGET_CPU_generic' is set as the default... Here is how the 'arm.h' sets the default to 'arm6' : ------------------ clip ------------------------------------------- /* Just in case configure has failed to define anything. */ #ifndef TARGET_CPU_DEFAULT #define TARGET_CPU_DEFAULT TARGET_CPU_generic #endif /* If the configuration file doesn't specify the cpu, the subtarget may override it. If it doesn't, then default to an ARM6. */ #if TARGET_CPU_DEFAULT == TARGET_CPU_generic #undef TARGET_CPU_DEFAULT #ifdef SUBTARGET_CPU_DEFAULT #define TARGET_CPU_DEFAULT SUBTARGET_CPU_DEFAULT #else #define TARGET_CPU_DEFAULT TARGET_CPU_arm6 #endif #endif ------------------ clip ------------------------------------------- If no '-mcpu=arm<xyz>' is used for GCC while compiling glibc, it of course will be produced for the default in GCC, ie for 'arm6'... But perhaps the aim was to use 'arm7tdmi' or something else... Adding the option into the CC definition (CC="gcc-arm-linux -mcpu=arm7tdmi") isn't tough however... Cheers, Kai ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |