[Top][All Lists]
[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
- Relinking to wrong version,
Dustin J. Mitchell <=