------- Comment #4 from oblivian at users dot sourceforge dot net 2008-04-03
00:12 -------
(In reply to comment #1)
> Sounds like you should be using --build-sysroot= and not set
> LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .
>
I pulled the compiler command that failed, and ran it with -v. I took that
command and ran it with the current stage ld.
Here is what GCC tries to run when linking libgcc_s.so.1.tmp
--------------------------------------------------------------
/media/disk/build/scripts/tools/toolchain-pass-1/build/./ld/ld-new
--sysroot=/tools --eh-frame-hdr -m elf_i386 -shared -o ./libgcc_s.so.1.tmp
/tools/usr/lib/crti.o
/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/crtbeginS.o
-L/media/disk/build/scripts/tools/toolchain-pass-1/build/./ld
-L/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc -L. -L/tools/lib
-L/tools/usr/lib --soname=libgcc_s.so.1 --version-script=libgcc.map _muldi3_s.o
_negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o
_mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o
_ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o
_popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o
_fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o
_fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o
_umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o
unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o
-lc /media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/crtendS.o
/tools/usr/lib/crtn.o
-----------------------------------------------
The error is...
-----------------------------------------------
/media/disk/build/scripts/tools/toolchain-pass-1/build/gcc/../ld/ld-new: cannot
find /tools/lib/libc.so.6 inside /tools
Now if I run the same command and take the /tools prefix off of the -L flags
for -L/tools/lib and -L/tools/usr/lib the library will link and running:
ldd libgcc_s.so.1.tmp
linux-gate.so.1 => (0xb7fce000)
libc.so.6 => /tools/lib/libc.so.6 (0xb7e90000)
/tools/lib/ld-linux.so.2 (0xb7fcf000)
So it seems that gcc should strip sysroot from the library paths if it is
calling a sysrooted ld, but should not if ld does not support sysroot. Even
though the ld gets search directories without the sysroot prefix it is linking
against the correct target libraries. For example, I can remove the --sysroot
from the first command above and run it with my host ld which doesn't support
sysroot (it's version 2.17 compiled the old way), and it will link the library
correctly and produce a ldd output the same as above pointing to the correct
locations.
Not sure where to go from here.
Also ran across a potential problem in binutils with elf32.em which does not
take into account sysroot correctly for the ld.so.conf path. The use_sysroot
flag is passed to the script, but it needs to use TARGET_SYSTEM_ROOT not prefix
to point to the correct sysroot /etc/ld.so.conf. For example my prefix for ld
configuration is /tools/usr whereas the sysroot is /tools. elf32.em will look
for it in /tools/usr/etc/ld.so.conf even though glibc installed it in
/tools/etc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804
