libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Relinking to wrong version


From: Dustin J. Mitchell
Subject: Relinking to wrong version
Date: Thu, 11 Oct 2007 16:41:20 -0500

Excuse the long intro here, but I'm not sure how to slim this down.
I'm running the following:

Gentoo Base System release 1.12.9
sys-devel/autoconf: 2.13, 2.61
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/libtool (project libtoolized with): 1.5.24
sys-devel/gcc: 4.1.2

I'm an Amanda developer, and I have a "production" copy of
amanda-2.6.2 installed in the usual system locations.  In particular:
-rwxr-xr-x 1 root root 226424 Jun  5 17:49 /usr/lib/libamanda-2.6.2.so
-rw-r--r-- 1 root root 442772 Jun  5 17:49 /usr/lib/libamanda.a
-rw-r--r-- 1 root root   1052 Jun  5 17:49 /usr/lib/libamanda.la
lrwxrwxrwx 1 root root     18 Jun  5 17:49 /usr/lib/libamanda.so ->
libamanda-2.6.2.so

I do my development installs under an easily-typed prefix of /A/p,
with a build dir of /A/b.  I'm building a libDevice.la that links
against libamanda.  From the relevant Makefile.am:
  libDevice_la_LIBADD = ... $(top_builddir)/common-src/libamanda.la
libamanda.la is built with the correct libdir='/A/p/lib/amanda'.  The
link step looks like this:

  /bin/sh ../libtool --tag=CC   --mode=link gcc -fno-strict-aliasing
-pipe -Wdeclaration-after-statement -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
-I/usr/lib64/perl5/5.8.8/x86_64-linux/CORE  -DSWIG -O0 -ggdb
-I/usr/include/openssl/ -pthread -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include    -avoid-version -module -L/usr/lib -o
libDevice.la -rpath /A/p/lib/amanda/perl/auto/Amanda/Device Device.lo
libamglue.la ../device-src/libamdevice.la ../common-src/libamanda.la
-lm -lreadline -Wl,--export-dynamic -pthread -lgmodule-2.0 -ldl
-lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0   -lnsl -lresolv -lssl
-lcrypto -lcrypto -L/usr/lib64 -lcurl -L/usr/lib -lssl -lcrypto -ldl
-lz
  gcc -shared  .libs/Device.o  -Wl,--rpath -Wl,/A/b/perl/.libs
-Wl,--rpath -Wl,/A/b/device-src/.libs -Wl,--rpath
-Wl,/A/b/common-src/.libs -Wl,--rpath -Wl,/A/p/lib/amanda -L/usr/lib
./.libs/libamglue.so -L/usr/lib64 ../device-src/.libs/libamdevice.so
../common-src/.libs/libamanda.so -lm -lreadline
/usr/lib64/libgmodule-2.0.so /usr/lib64/libgobject-2.0.so
/usr/lib64/libgthread-2.0.so -lrt /usr/lib64/libglib-2.0.so -lnsl
-lresolv /usr/lib64/libcurl.so -lssl -lcrypto -ldl -lz  -pthread
-Wl,--export-dynamic -pthread -Wl,-soname -Wl,libDevice.so -o
.libs/libDevice.so

Looks good:
address@hidden /A/b/perl $ ldd .libs/libDevice.so  | grep libamanda
        libamanda-2.6.3.so => /A/b/common-src/.libs/libamanda-2.6.3.so
(0x00002aac7ede9000)

The problem comes when, on 'make install', libtool relinks the library:
 /bin/sh ../libtool --mode=install /usr/bin/install -c  'libDevice.la'
'/A/p/lib/amanda/perl/auto/Amanda/Device/libDevice.la'
libtool: install: warning: relinking `libDevice.la'
(cd /A/b/perl; /bin/sh ../libtool  --tag=CC --mode=relink gcc
-fno-strict-aliasing -pipe -Wdeclaration-after-statement
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
-I/usr/lib64/perl5/5.8.8/x86_64-linux/CORE -DSWIG -O0 -ggdb
-I/usr/include/openssl/ -pthread -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -avoid-version -module -L/usr/lib -o
libDevice.la -rpath /A/p/lib/amanda/perl/auto/Amanda/Device Device.lo
libamglue.la ../device-src/libamdevice.la ../common-src/libamanda.la
-lm -lreadline -Wl,--export-dynamic -pthread -lgmodule-2.0 -ldl
-lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lnsl -lresolv -lssl
-lcrypto -lcrypto -L/usr/lib64 -lcurl -L/usr/lib -lssl -lcrypto -ldl
-lz )
gcc -shared  .libs/Device.o  -Wl,--rpath -Wl,/A/p/lib/amanda
-L/usr/lib -L/A/p/lib/amanda -lamglue -L/usr/lib64 -lamdevice -lamanda
-lm -lreadline -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lrt
-lglib-2.0 -lnsl -lresolv -lcurl -lssl -lcrypto -ldl -lz  -pthread
-Wl,--export-dynamic -pthread -Wl,-soname -Wl,libDevice.so -o
.libs/libDevice.so

And here's where the trouble starts: libtool rewrote
'../common-src/libamanda.la' to '-lamanda' (it initially included
'-L../common-src/.libs', but that was dropped later in the script
execution -- I couldn't tell exactly where).

The gcc linker looks around for libamanda.so, and finds the existing
(2.6.2) library.  It reads the symlink, and adds a NEEDED for the
version-specific filename:
address@hidden /A/b/perl $ readelf -a
/A/p/lib/amanda/perl/auto/Amanda/Device/libDevice.so   | grep
libamanda
 0x0000000000000001 (NEEDED)             Shared library: [libamanda-2.6.2.so]

Consequently, when I try to run the development version in /A/p, 'ld'
looks for libamanda-2.6.2.so; since /A/p/lib/amanda (which is in
libDevice.so's RPATH) contains libamanda-2.6.3.so, the search
continues, and it links against the version in /usr/lib.  If I rename
the /A/p/lib/amanda/libamanda-2.6.3.so to ..-2.6.2.so, then the link
is successful.

It's not clear to me whether this would affect Amanda users installing
a new version of Amanda over an old one, but it is problematic for me!
 Is this a bug?  Can someone suggest a workaround, either as a change
I can make to my development environment, as a patch to the ltmain.sh
that can is included the Amanda repository?

TIA
Dustin

-- 
Storage Software Engineer
http://www.zmanda.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]