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]

Re: (fwd) BUG IN DYNAMIC LINKER ld.so:


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]