[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool 1.5.20, Solaris, linking in static libraries into the shared
From: |
Pooh |
Subject: |
Re: libtool 1.5.20, Solaris, linking in static libraries into the shared libraries |
Date: |
Mon, 31 Oct 2005 17:38:52 +0300 |
User-agent: |
Mozilla Thunderbird 1.0.7 (Windows/20050923) |
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.