Re: ld trapped in endless loop (was Re: config? bootstrap on hppa64-hp-hpux11.0 with --enable-shared still fails)

[Ian Lance Taylor]

Markus Werle <address@hidden> writes:

> I tried by hand using additional flag -Wl,--verbose.
> Error message attached.
> ld finds libm.sl but restarts searching for it. Is that correct behaviour?
> 
> /work/markus/GCC/build-64/gcc/xgcc -Wl,--verbose 
> -B/work/markus/GCC/build-64/gcc/ -nostdinc++  
> -L/work/markus/GCC/build-64/hppa64-hp-hpux11.00/libstdc++-v3/src
> -L/work/markus/GCC/build-64/hppa64-hp-hpux11.00/libstdc++-v3/src/.libs 
> -B/opt/FREE-SOFTWARE/gcc-3.0.2-64/hppa64-hp-hpux11.00/bin/
> -B/opt/FREE-SOFTWARE/gcc-3.0.2-64/hppa64-hp-hpux11.00/lib/ -isystem 
> /opt/FREE-SOFTWARE/gcc-3.0.2-64/hppa64-hp-hpux11.00/include -shared -nostdlib
> .libs/basic_file.o .libs/bitset.o .libs/c++locale.o .libs/cmath.o 
> .libs/codecvt.o .libs/complex_io.o .libs/functexcept.o .libs/globals.o 
> .libs/ios.o
> .libs/limits.o .libs/locale.o .libs/locale-inst.o .libs/localename.o 
> .libs/misc-inst.o .libs/stdexcept.o .libs/stl-inst.o .libs/string-inst.o 
> .libs/strstream.o
> .libs/valarray-inst.o .libs/wstring-inst.o -Wl,--whole-archive 
> ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a 
> -Wl,--no-whole-archive
> -L/work/markus/GCC/build-64/hppa64-hp-hpux11.00/libstdc++-v3/src 
> -L/work/markus/GCC/build-64/hppa64-hp-hpux11.00/libstdc++-v3/src/.libs -lm
> ../libmath/.libs/libmath.a -lm ../libsupc++/.libs/libsupc++convenience.a -lm 
> -L/work/markus/GCC/build-64/gcc
> -L/opt/FREE-SOFTWARE/gcc-3.0.2-64/hppa64-hp-hpux11.00/bin 
> -L/opt/FREE-SOFTWARE/gcc-3.0.2-64/hppa64-hp-hpux11.00/lib -L/opt/langtools/bin
> -L/opt/langtools/lib/pa20_64 -L/opt/langtools/lib -lm -lc   -Wl,-soname 
> -Wl,libstdc++.sl.3 -o .libs/libstdc++.sl.3.2 2>&1 | tee ~/ld_errors

Note that your command line includes
    -lm ../libmath/.libs/libmath.a -lm
This tells the linker to use -lm twice.  -lm maps to libm.sl.  It's
not efficient in this case for the linker to use the full search path
again the second time it looks for -lm, but it's not wrong.

> yields error message:
> collect2: ld terminated with signal 11 [Segmentation fault]

This is certainly a bug.  Searching for -lm twice is not the problem.

Ian