This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more infromation.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |