Re: libtool 1.5.20, Solaris, linking in static libraries into the shared libraries
Hi Yuri, * Pooh wrote on Mon, Oct 31, 2005 at 03:38:52PM CET: > Ralf Wildenhues wrote: > > > >>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 I forgot to say that above bugfix was C, not C++. > >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. Thank you for checking. Could I ask another favor? Could you try the same thing for the C compiler driver, and maybe also for the Fortran ones (again including versions and stuff)? Thank you very much. > >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? *snip* > The answer to your question: on all four platforms it is being linked > dynamically. Great! Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool 1.5.20, Solaris, linking in static libraries into the shared libraries
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. ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libtool 1.5.20, Solaris, linking in static libraries into the shared libraries
Hi Yuri, * Pooh wrote on Mon, Oct 31, 2005 at 11:31:24AM CET: > > There is a following problem using CC v5.5 (v5.6 from Studio 10 does > show the same behaviour). > I compile the sources (attached). > test1 prints the message, while test2 doesn't. > > That is because when we compile static library into the shared, using > the string: (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). > 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?) > PS. *giggle* I remember that some time ago this has been changed into > the current form because of a problem with CC5.3 on Solaris 8. Yes, I know. On CVS HEAD, I'll probably just set whole_archive_flag_spec= so libtool will do the extracting and not use `allextract' at all, because of above mentioned dummy-bug. > On 5.3 it still doesn't work in any form. But on 5.5 and 5.6 it helps. > So the idea "wl=-z" looks better and better:) 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..) 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. Thanks, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
libtool 1.5.20, Solaris, linking in static libraries into the shared libraries
Excuse me, i have forgotten the attach in last message, now i resend. Good day! There is a following problem using CC v5.5 (v5.6 from Studio 10 does show the same behaviour). I compile the sources (attached). test1 prints the message, while test2 doesn't. That is because when we compile static library into the shared, using the string: 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 PS. *giggle* I remember that some time ago this has been changed into the current form because of a problem with CC5.3 on Solaris 8. On 5.3 it still doesn't work in any form. But on 5.5 and 5.6 it helps. So the idea "wl=-z" looks better and better:) test.tar.gz Description: GNU Zip compressed data ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
