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:
GCC is version 4.1.1
Binutils 2.17
Glibc is CVS head.

When configuring gcc, I used --with-sysroot=/path/to/sysroot,
where glibc is installed under usr/. The header files are
found correctly.
What about the binutils, was the same '--with-sysroot='
given in their configure?

Finding the headers happens with the built-in 'cpp' in the
'cc1', 'cc1plus' etc. real compilers, so only the GCC config
options will have any influence to this.

When the linker is invoked, it is given

--sysroot=/path/to/sysroot.
Maybe this option is aimed for a 'ld' which was NOT configured
using the '--with-sysroot='...
The linker resolves  -lc  to the absolute name
/path/to/sysroot/usr/lib/libc.so.6. But then it catenates that
to the sysroot, resulting in

/path/to/sysroot/path/to/sysroot/usr/lib/libc.so.6 which is nonsense.

I can see using strace that it's actually trying to access that path.
And so it dies with "cannot find /path/to/sysroot/lib/libc.so.6
inside /path/to/sysroot".

So, what's the /right/ way to coordinate the location of the
target headers and libraries between gcc and binutils when
cross-compiling?
My guess after seeing this "behaviour" would be to NOT use the
'--with-sysroot=' in the binutils configure with the newer binutils like
the '2.17'....  The GCC configured with it then giving that necessary
'--sysroot=/path/to/sysroot' to the linker. And the older GCCs which
didn't have the '--with-sysroot=' of course not giving that...

Meanwhile any binutils configured using '--with-sysroot=', would add
the necessary 'offsets' automatically, so also the older GCCs could be
capable to use the 'sysroot'ed C library...

I myself haven't used the '--with-sysroot=', only made symlinks like :

    $prefix/$target/include  ->  $sysroot/usr/include
    $prefix/$target/lib  ->  $sysroot/usr/lib

because the 'usr/lib' already has symlinks to '../../lib' for the majority
of its shared '.so' files, only symlinks to the '../../lib/libc.so.6' and to the
'../../ld-linux.so.2' (or '../../lib/ld.so.1' or something) must be manually
added just as editing the 'libc.so' script to not have any absolute paths
in its 'libc.so.6 libc_nonshared.a' or something GROUP row... This has
been the "right" way for me because of using GCCs BEFORE the new
'--with-sysroot=' appeared, and still having those pre-gcc-3.3.3 or what
was the GCC version where this option appeared... The Robert Heinlein's
"By-Law of Time": "If At Last You Do Succeed, Never Try Again", which
is so common among the most crosscompiler builders - they really seem
to build their crosscompilers only once, or if being obliged to do that
again, then starting everything from scratch again - is not understood
by me :-(


Using 5 or so GCC versions with the same $target binutils in $prefix/bin
and in $prefix/$target/bin, would cause me problems if trying to use the
'--with-sysroot'... So things are easier with using only the idea, not really
using the full implementation...






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