This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gcc+binutils+libc cross-compiling: path to libc.so.6 malformed in "ld".


Kaz Kylheku wrote :
Solved!

This problem is caused by a miscconfigured glibc build with an incorrect
--prefix. The absolute paths are picked up from libc.so, which is just a
linker script generated by glibc.  This linker script must contain paths
that are correct for the target system system. Of course, those paths
don't work on the cross-compiling system, which is where the catenation
with --sysroot comes in.
What I have thought being the aim in producing a "normal" glibc,
one which should work both as a "native" glibc, and as a "cross"
glibc, is using the '--prefix=/usr'. Then the install scheme includes
the '.../lib' and the '.../usr/lib'. In a native install the '.../' is the '/'
and in a cross install it is the '$sysroot/'.


So the resulted 'libc.so' has just the same 'native' like pathnames :

/* GNU ld script
  Use the shared library, but some functions are only in
  the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )

and the 'libpthread.so' script too :

/* GNU ld script
  Use the shared library, but some functions are only in
  the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )

And because of using the '--with-sysroot=$sysroot', the 'ld' interprets
these absolute paths to mean '$sysroot/lib/...' and '$sysroot/usr/lib/...' !

Otherwise the '--with-sysroot=' simply doesn't work "as expected"...

Being able to copy a glibc (plus the other target libraries) between the
native and the cross host(s) in 1-to-1 scheme (just as any other target C
libraries, the proprietary ones don't even have any sources so copying
them is the only possibility... And of course rebuilding already built libs
for the Linux distros is quite stupid!) should be the motive for using the
'--with-sysroot=' ! Traditionally this hasn't succeeded, fixing some things
has been obligatory because the cross GCC scheme knows only one 'lib'.


If you use the '--prefix=/usr' in your glibc configure and use the suggested

make install_root=$sysroot

to install it below the $sysroot, the glibc should be there waiting that
1-to-1 copying onto the native target system.  And should work in your
crosstoolchain, that configured using the '--with-sysroot=$sysroot' !


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]