[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multiply-defined symbols problem on solaris9 (libtool-1.5.18)
From: |
Ralf Wildenhues |
Subject: |
Re: multiply-defined symbols problem on solaris9 (libtool-1.5.18) |
Date: |
Fri, 19 Aug 2005 16:28:06 +0200 |
User-agent: |
Mutt/1.4.1i |
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