Re: libtool 1.5.20, Solaris, linking in static libraries into the shared libraries

[Pooh]

Ralf Wildenhues wrote:

> (Side note: you mean what in Libtool lingo is called a `convenience
> archive' rather than a static library;  the objects in the archive
> contain position-independent code, PIC).
>  
Oh, yes. I remember that one.

>  
>
> > libtool --mode=link CC -rpath /tmp -o libcon2.la dummy.lo libcon.la
> > It becomes:
> > CC -G -hlibcon2.so.0 -o .libs/libcon2.so.0.0.0   .libs/dummy.o -Qoption 
> > ld -z -Qoption ld allextract,./.libs/libcon.a -Qoption ld -z -Qoption ld 
> > defaultextract  -lCstd -lCrun -lc
> > Which is considered wrong, the string must look like:
> > CC -G -hlibcon2.so.0 -o .libs/libcon2.so.0.0.0   .libs/dummy.o -z 
> > allextract ./.libs/libcon.a -z defaultextract  -lCstd -lCrun -lc
> > As stated here: http://forum.sun.com/thread.jspa?threadID=27249&tstart=0
> >    
>
> There is a partly related bugfix pending:
> http://lists.gnu.org/archive/html/libtool-patches/2005-10/msg00111.html
>
> Does
>  CC -G -hlibcon2.so.0 -o .libs/libcon2.so.0.0.0  -z \
>    allextract ./.libs/libcon.a -z defaultextract  -lCstd -lCrun -lc
>
> work as well?  For which compiler/Solaris versions (print `CC -V')?
> (I assume not, that's probably why you added the dummy.lo in the first
> place, right?)
>  
Yes, dummy.lo is about this matter, somewhere someday in my projects it 
didn't work... But when i try your line now, it works on CC v5.5 and v5.6.

> What I haven't understood yet is why we use `-Qoption' at all.  There
> must be some combination where `-z' doesn't work as expected.  (Haven't
> checked the archives for this yet..)
>  
On CC v5.3  if we write
CC ... -z allextract libfoo.a -z defaultextract ...,
It becomes
ld ... -z allextract -z defaultextract....
While
CC ... -Qoption ld -z,allextract,.libfoo.a -Qoption ld -z,defaultextract
Becomes
ld ... -z allextract libfoo.a -z defaultextract
I wrote about it to bug-libtool in march (about 08.03). For 5.3 it was 
ok, but now -Qoption ld seems deprecated, and first approach works on my 
5.5 (patched and not) and 5.6.

> By the way, another question (since you seem to have access to a number
> of compiler/system version):  Does the addition of `-lCstd -lCrun' cause
> the C++ library symbols to be copied into the created library, or are
> they linked dynamically?  If the former: for which compiler/system
> versions?  You should read this thread for more info on this:
> http://lists.gnu.org/archive/html/libtool/2005-08/msg00088.html
> If you can provide additional useful information, the better, but be
> sure to always specify which compiler/system versions you are speaking
> about.
>  
Ok. So i currently have (uname -a, CC -V)
1) SunOS build-s8 5.8 Generic_108529-27 i86pc i386 i86pc
   CC: Sun WorkShop 6 update 2 C++ 5.3 2001/05/15
2) SunOS build-s9 5.9 Generic_112234-08 i86pc i386 i86pc
   CC: Sun C++ 5.5 2003/03/12
3) SunOS baldr 5.9 Generic_112233-08 sun4u sparc SUNW,Sun-Fire-280R
   CC: Sun C++ 5.5 Patch 113817-09 2004/08/03
4) SunOS sols64 5.10 s10_72 sun4u sparc SUNW,Sun-Blade-100
   CC: Sun C++ 5.6 2004/07/15

The answer to your question: on all four platforms it is being linked 
dynamically.