Re: CrosGCC: [cross]compiling egcs/gcc with glibc headers

[Kai Ruottu <karuottu at freenet dot hut dot fi>]

Brendan John Simon wrote:
> 
> Kai Ruottu wrote:
> 
> > Brendan John Simon wrote:
> > >
> > > I'm trying to cross-compile gcc-2.95.2 and egcs-1.1.2 for a
> > > powerpc-linux system. I would prefer to use gcc-2.95.2 but it has
> > > problems compiling glibc-2.1.1 and glibc-2.1.2.  It complains about
> > __libc_global_constructors not being defined.
>
> This happens with both the native compile AND the cross compile using
> gcc-2.95.2.  I have just recompiled my native tools (binutils-2.9.5.0.24,
> egcs-1.1.2) and glibc-2.1.x still fails.  This leads me to believe that
> is NOT gcc-2.95.2, but binutils-2.95.x (or maybe my kernel headers ?).

 Have you tried a 'nm' for binaries, 'grep' for sources, to solve where the
missing name is ?   My 2.0.7 libs have it in 'libc.so', but not in 'libc.a' :

-------------------------- clip ----------------------------
E:\usr\local\i486-linux-gnu\lib>nm libc.so | grep libc_global
0000000000015ff0 T __libc_global_ctors

E:\usr\local\i486-linux-gnu\lib>
-------------------------- clip ----------------------------

 I looked also the prebuilt '2.1' libs I already had, and surprisingly found
the symbol being local there (a small 't' in the 'nm' output)...

 Doing a 'grep libc_global_ctors *.c */*.c */*/*.c ...' didn't take much time,
and it revealed the symbol being needed also elsewhere...

> Do you actually install a new kernel or are the kernel headers enough ?

 The kernel sources must be 'configured', i.e. at least a 'make include/linux/version.h'
must be run. The '--with-headers=something' must be used to point to the kernel headers,
otherwise they will be searched from '/usr/include/asm' and '/usr/include/linux'.  So it
must be used for this purpose, unlike I wrote earlier...

> I have been using 2.2.6 for the native compile and 2.2.5 for the cross-compile.
> I will probably got 2.2.13 or 2.2.14.

 The FAQ should tell what will be needed... Perhaps there are other RTFM-issues...  I
only browsed them a little and found explanations for many (earlier) weird things, like
why the shared the libs compiled with egcs-1.1.2 don't work with binaries compiled with
gcc-2.7.2.x or gcc-2.8.1...

> >  Building GCC using the new glibc-2.1.x may perhaps work only when the glibc-2.1.x
> > has been installed. So you probably need to build gcc-2.95.2 first using your
> > current headers & libs, build glibc-2.1.x using it, install glibc-2.1.x and rebuild
> > gcc-2.95.2 with glibc-2.1.x. Or the things may be more complicated, I cannot say
> > how well (or if at all) old glibc-2.0.7-based binaries will run with glibc-2.1.x
> > shared libraries.
> 
> This is what am now trying, but egcs now fails when I use binutils-2.9.9.x.

 I managed to build the native glibc-2.1.2 using the old glibc-2.0.7 based toolset I
had... (This was the C-library in RH5.2 as far as I remember). Trying 'arm-linux' needed
some newer headers than those provided with the kernel-2.2.9 sources (RH6.0 etc.) I had
(the errors said something being missing in the 'asm-arm' headers...)

 So my conclusion is that there is something basically wrong with the glibc-2.1(.0). You
didn't mention the version for your current C-library, but it must be '2.1'.  The '2.1.2'
I got had the 'T __libc_global_ctors' exported again, not the 't __libc_global_ctors' as
in '2.1'. The error you got is most probably coming from some linking done against your
current C-library...

 Perhaps the only cure could really be to find some prebuilt glibc-2.1.1 or 2.1.2 for the
native system, and then rebuild the glibc-2.1.2 sources. Going backwards to 2.0.7 may not
work...

 For your link search problems here are some rules :

 - the '--dynamic-linker xyz' must always be the same for a native or a cross-compiler,
   it simply says where the linked executable finds the dynamic linker when running. If
   you cannot replace the '/lib/ld-linux.so.2' in your native system with the 2.1.x one
   (why not ?), you have a special system which breaks the current 'Linux-standard'...
   Or there is a serious uncompatability issue between 2.1 and 2.1.x... 

 - the '-rpath' gives the extra search directories for the shared libs for a running
   executable (additionally with the '/lib', '/usr/lib' etc. which will be searched
   automatically).

 - the '-rpath-link' gives the search path when linking the executable against all the
   '.so' files in a cross-development environment, where the '.so' files  cannot be in
   their normal places. Basically this rule is wrong, but perhaps easier to remember...

   As Ian wrote some time ago, it just tells where to find those chained '.so' files,
   e.g. 'libc.so' needs 'ld-linux.so.2', so it must be searched too... Why it doesn't find all
   the 'libs' in those directories given by the '-L's to the linker, may be a bug or not, but
   currently the '-rpath-link' is needed for cross-compilers which produce executables against
   shared libs and have links between the shared libs.  But it could perhaps be easier to
   remember, if taken wrongly as "the search path for the .so files' in a cross-development
   environment".

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