Re: Solaris 9 + gcc

[Ralf Wildenhues]

* Mark Andrews wrote on Wed, Dec 08, 2004 at 05:58:45AM CET:
> 
>       If a shared library requires libgcc the library path is not
>       recorded in the .la file.  This causes executables linked
>       against the library to fail.

I don't think this is the reason for the failure, but I'm not sure.

> Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3.2/specs
> Configured with: ../configure --with-as=/usr/ccs/bin/as 
> --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj 
> --enable-languages=c,c++ : (reconfigured) ../configure 
> --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls 
> --disable-libgcj --enable-languages=c,c++
> Thread model: posix
> gcc version 3.3.2
> 
>       named1 just arranges for ldd to be called with the appropriate
>       LD_LIBRARY_PATH.
> 
> sol.lab.isc.org:named 04:50 {15} % grep ldd named1
>       exec ldd $progdir/$program ${1+"$@"}
> sol.lab.isc.org:named 04:50 {16} % 
> 
> sol.lab.isc.org:named 03:20 {18} % ./named1
>         liblwres.so.1 =>         
> /udir/marka/cvs/9.3.x/bin/named/../../lib/lwres/.libs/liblwres.so.1
>         libdns.so.20 =>  
> /udir/marka/cvs/9.3.x/bin/named/../../lib/dns/.libs/libdns.so.20
>         libbind9.so.0 =>         
> /udir/marka/cvs/9.3.x/bin/named/../../lib/bind9/.libs/libbind9.so.0
>         libisccfg.so.1 =>        
> /udir/marka/cvs/9.3.x/bin/named/../../lib/isccfg/.libs/libisccfg.so.1
>         libcrypto.so.0.9.7 =>    /usr/local/ssl/lib/libcrypto.so.0.9.7
>         libisccc.so.0 =>         
> /udir/marka/cvs/9.3.x/lib/isccc/.libs/libisccc.so.0
>         libisc.so.9 =>   /udir/marka/cvs/9.3.x/lib/isc/.libs/libisc.so.9
>         libnsl.so.1 =>   /usr/lib/libnsl.so.1
>         libsocket.so.1 =>        /usr/lib/libsocket.so.1
>         libpthread.so.1 =>       /usr/lib/libpthread.so.1
>         libthread.so.1 =>        /usr/lib/libthread.so.1
>         libc.so.1 =>     /usr/lib/libc.so.1
>         libgcc_s.so.1 =>         (file not found)

Here it's not found,

>         libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1

here it is.

>         libdl.so.1 =>    /usr/lib/libdl.so.1
>         libmp.so.2 =>    /usr/lib/libmp.so.2
>         /usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
> sol.lab.isc.org:named 03:22 {22} % ldd 
> /udir/marka/cvs/9.3.x/bin/named/../../lib/lwres/.libs/liblwres.so.1
>         libnsl.so.1 =>   /usr/lib/libnsl.so.1
>         libsocket.so.1 =>        /usr/lib/libsocket.so.1
>         libpthread.so.1 =>       /usr/lib/libpthread.so.1
>         libthread.so.1 =>        /usr/lib/libthread.so.1
>         libc.so.1 =>     /usr/lib/libc.so.1
>         libgcc_s.so.1 =>         (file not found)

Here, again, it's not.

>         libdl.so.1 =>    /usr/lib/libdl.so.1
>         libmp.so.2 =>    /usr/lib/libmp.so.2
>         /usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
> sol.lab.isc.org:named 03:22 {23} %

My guess: libtool variable sys_lib_dlsearch_path_spec contains
/usr/local/lib, but the dynamic linker does not search it?
The problem does not go away after using `crle'?  The configuration for
crle does not contain /usr/local/lib as trusted directory?
(Why does libtool not use crle BTW?)

You are not the first one to report problems with libgcc on Solaris.
I don't feel too qualified to work on this, because I don't have access
to it and never used it before.  I'm not sure what the real problem is
in this case.  Help wanted (the libtool maintainer crew is understaffed
ATM).

Regards,
Ralf