------- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-26 02:50 ------- Subject: Re: Default path for libgcc_s.sl is build directory
> Isn't this really still a dup of bug 5291? Yes. I got bitten by the bug today ;( Regarding comment #8 in PR 5291: > Note that, on PA, the linker does indeed annotate an executable with the > location in which it found the library, but that's just a cache, it doesn't > require the library to be there in order to function. Libtool knows about > that, > and does the right thing when linking with a libtool library, but libgcc_s > isn't > a libtool library, so libtool can't do much. It's correct that the linker does annotate an executable with the location in which it finds a library when it is linked in with -l and the dynamic linker doesn't require the library to be there in order to function, but the dynamic linker will use an executable file with the correct name if it finds it in preference to doing a path search. So, one has to be very careful about doing builds for different versions and targets in different locations. The hppa64-*-hpux* situation is a little different: /bin/sh ../libtool --tag CXX --mode=link /test/gnu/gcc-4.1/objdir/./gcc/xgcc -shared-libgcc -B/test/gnu/gcc-4.1/objdir/./gcc -nostdinc++ -L/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -B/opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/sys-include -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o libstdc++.la -rpath /opt/gnu64/gcc/gcc-4.1.0/lib -version-info 6:7:0 -lm bitmap_allocator.lo pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo ctype.lo debug.lo debug_list.lo functexcept.lo globals_locale.lo globals_io.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo list.lo locale.lo locale_init.lo lo! cale_facets.lo localename.lo stdexcept.lo strstream.lo tree.lo allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo ios-inst.lo iostream-inst.lo istream-inst.lo istream.lo locale-inst.lo locale-misc-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo c++locale.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. The result is libgcc_s isn't linked against libstdc++. I had a hppa64 libtool patch that fixed a lot of problems on this port (it needs to be handled in a manner very similar to ia64-hpux) but gave when the patch was ignored upstream. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26472
