This is the mail archive of the gcc-bugs@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]

[Bug target/26472] Default path for libgcc_s.sl is build directory



------- 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


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