Re: multiply-defined symbols problem on solaris9 (libtool-1.5.18)
Hi Derek, * Derek Feichtinger wrote on Fri, Aug 19, 2005 at 02:36:22PM CEST: > > I have a problem with multiply-defined symbols from two convenience libraries > causing a link problem when I build a shared libtool library. This only > happens to me on a number of solaris9 installations with the Forte Developer > 7 C++ compiler. > > libtool version: 1.5.18 > I use automake-1.6 and autoconf-2.59. > > The multiply-defined symbols in libXrdNet and libXrdOuc (see output lines > below) derive from template instantiations. In other compilers the symbols > get included into the archives as WEAK symbols, so the linking is fine. But > on this SUN Forte compiler the symbols are not weak and a clash happens. OK. Libtool support for template libraries could be better. OTOH, templates and shared libraries sometimes just don't work very well together. > I can compile it from the command line if I modify the link line to contain > either '-xar' or if I change the '-z -Qoption ld allextract,...' to > '-z -Qoption ld defaultextract'. Do you know whether -xar is safe to use for shared libraries? A quick glance at the docs does not reveal any clue to me. I've started to work on supporting template libs better in Libtool. The CVS HEAD version has a couple of improvements, but so far only for the PGI compiler. It seems, all template instantiation methods other than GCC's lack some flexibility in order to be used successfully with Libtool. If a way can be found to make it work with SUN Forte, I'd be happy to put it in HEAD. Meanwhile, can I ask a favor of you? We've changed the code for -no-undefined on Solaris, and I'd like a test with a real-world example C++ package before I release 1.5.20 this weekend. Could you try it (or point me to the package you're compiling so I can)? I could send you a bootstrapped Libtool tarball (off-list) if you like. > Is there a way of communicating this in a simple way to libtool or does it > require a patch? libtool silently ignores my attempts to get '-xar' on the > command line, if I try to override the linker specification in configure to > be 'CC -xar' (i.e. the libtool line still contains it, but after processing > with libtool it is gone) You can do "-Wl,-xar" on the link line, that should help as a workaround. > Libtool output: > > /bin/bash ../../libtool --mode=link CC -DSUNCC -D_POSIX_PTHREAD_SEMANTICS > -xarch=v8plus -D_REENTRANT -L/usr/local/lib -mt -o libXrdSec.la > -rpath /tmp/compiletest/install/lib -ldl XrdSecClient.lo XrdSecPManager.lo > XrdSecProtocolhost.lo > XrdSecServer.lo ../XrdOuc/libXrdOuc.la ../XrdNet/libXrdNet.la -lssl > > > CC -G -nolib -hlibXrdSec.so.0 > -o .libs/libXrdSec.so.0.0.0 .libs/XrdSecClient.o .libs/XrdSecPManager.o > .libs/XrdSecProtocolhost.o .libs/XrdSecServer.o > -Qoption ld -z -Qoption ld > allextract,../XrdOuc/.libs/libXrdOuc.a,../XrdNet/.libs/libXrdNet.a -Qoption > ld -z -Qoption ld defaultextract -L/usr/local/lib -ldl -lpthread -lrt > -lsocket -lnsl -lssl -mt Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: multiply-defined symbols problem on solaris9 (libtool-1.5.18)
Hi, Ralf thanks very much for this speedy response. > Do you know whether -xar is safe to use for shared libraries? > A quick glance at the docs does not reveal any clue to me. I have too limited Solaris experience to answer that, but from what I see now it's probably not a good idea. I can see now, that just doing this CC -G -nolib -hlibXrdSec.so.0 -o .libs/libXrdSec.so.0.0.0 .libs/XrdSecClient.o .libs/XrdSecPManager.o .libs/XrdSecProtocolhost.o .libs/XrdSecServer.o ../XrdOuc/.libs/libXrdOuc.a ../XrdNet/.libs/libXrdNet.a ... without any kind of -QOptions also does the job (and this was actually used in the build system of the project which I am currently moving to autotools). I have dicovered some old mails on you list about the introduction of the QOptions with allextract, but it was in another context. > I've started to work on supporting template libs better in Libtool. > The CVS HEAD version has a couple of improvements, but so far only for > the PGI compiler. It seems, all template instantiation methods other > than GCC's lack some flexibility in order to be used successfully with > Libtool. > > If a way can be found to make it work with SUN Forte, I'd be happy to > put it in HEAD. Great. Thanks. > Meanwhile, can I ask a favor of you? We've changed the code for > -no-undefined on Solaris, and I'd like a test with a real-world example > C++ package before I release 1.5.20 this weekend. Could you try it (or > point me to the package you're compiling so I can)? I could send you a > bootstrapped Libtool tarball (off-list) if you like. Sure. I'll try to do it tomorrow morning or tonight. The bootstrapped Libtool tarball would be easiest for me. What should I do to test it? Cheers, Derek ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: multiply-defined symbols problem on solaris9 (libtool-1.5.18)
Hi Derek, * Derek Feichtinger wrote on Fri, Aug 19, 2005 at 05:32:03PM CEST: > > > Do you know whether -xar is safe to use for shared libraries? > > A quick glance at the docs does not reveal any clue to me. > > I have too limited Solaris experience to answer that, but from what I > see now it's probably not a good idea. In your previous example, you use convenience archives. It is one issue whether they work with C++ templates, but is is a different matter whether static or shared archives work well with C++ template instantiation mechanisms. > I can see now, that just doing this > > CC -G -nolib -hlibXrdSec.so.0 > -o .libs/libXrdSec.so.0.0.0 .libs/XrdSecClient.o .libs/XrdSecPManager.o > .libs/XrdSecProtocolhost.o .libs/XrdSecServer.o ../XrdOuc/.libs/libXrdOuc.a > ../XrdNet/.libs/libXrdNet.a > ... > > without any kind of -QOptions also does the job (and this was actually > used in the build system of the project which I am currently moving to > autotools). I have dicovered some old mails on you list about the > introduction of the QOptions with allextract, but it was in another > context. Never mind that mail; IIRC, that was merely about how to correctly pass allextract through to the linker. Please read both info Libtool "Static libraries" and the info about convenience archives from this thread: http://lists.gnu.org/archive/html/libtool/2005-08/msg00078.html to learn about what exactly convenience archives are. (to-be merged into documentation proper) Then you can maybe decide if you need convenience archives. I'm not sure. But if you do, and I'd guess so, then your link line above may miss objects, silently. And one of the users of your installed libXrdSec.so.0 might complain much later. So the approach with -Wl,-xar might be the correct one for you. Do any of the convenience archives you use in the broken link consist of other subsumed convenience archives? Maybe two even share the same? (With templates, this does not have to be the case, but I'd like to make sure, even if your previous mail hinted at the other cause.) > > Meanwhile, can I ask a favor of you? We've changed the code for > > -no-undefined on Solaris, and I'd like a test with a real-world example > > C++ package before I release 1.5.20 this weekend. Could you try it (or > > point me to the package you're compiling so I can)? I could send you a > > bootstrapped Libtool tarball (off-list) if you like. > > Sure. I'll try to do it tomorrow morning or tonight. The bootstrapped Libtool > tarball would be easiest for me. What should I do to test it? In another mail. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: multiply-defined symbols problem on solaris9 (libtool-1.5.18)
Hi Derek, * Derek Feichtinger wrote on Tue, Aug 30, 2005 at 09:19:04AM CEST: > > I have more or less given up to get the project I am porting to autotools to > compile on Solaris9 with the Forte-7 compiler. With the newer Sun compilers > it works well, so I think it does not pay off to do a lot of crazy tricks to > get this infamous combination to work. OK. > Details for those who are interested: > > The problem has to do with the C++ template instantiation mechanism used in > this old compiler: > - In every directory where an object is created, the compiler places a > SunWS_cache directory with the template related objects. What you could try to use only one big Makefile (see "info Automake Alternative") and do not build convenience libraries at all, but go straight for the output library. > - The symbols in these objects are not (as in other compilers) defined as > weak. That itself is not the biggest problem. The issue with subdirectories is usually that the linker does not find the corresponding cache/template directories. > This completely prevents the sensible use of convenience libraries and > integrating them in an encompassing shared library, because if two of them > work with the same template instantiations, one gets multiply defined > symbols. If someone can give me access to both this compiler suite (a login or a debug-over-email session would both work) and possibly also to the project or a small example that reproduces the failures, I could look into this issue myself. It'd be a few weeks, though, other issues are more important at the moment. > One could rearrange the build structure of a project (directory layout) so > that in the end one manages to compile the thing with the current libtool, > but I think it's just not worth it. One looses all the nice structure that > libtool offers, just to accomodate this old compiler. On all kind of Linuxes, > MacOS, and newer Sun compilers the thing works perfectly. That's good to know! > > > > Do you know whether -xar is safe to use for shared libraries? > > > > A quick glance at the docs does not reveal any clue to me. > > The documents state that -xar is just for static archives while -G does the > same for dynamic libraries. Still I was able to compile one of my libraries > using "-G -xar" and I did not see the multiply defined symbols error there. I > got other problems later. The behavior seems to be undefined and I would not > recommend it. As said above, if you have something reproducible, and/or can show the failures, we might be able to help a bit more. > Sorry, Ralf. Because of all these above problems, I was not able to test the > tarball you sent me. No problem at all. In any case, thanks for the heads-up! Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
