[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/
-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/
lrwxrwxrwx 1 root root     18 Jun  5 17:49 /usr/lib/ ->

I do my development installs under an easily-typed prefix of /A/p,
with a build dir of /A/b.  I'm building a that links
against libamanda.  From the relevant
  libDevice_la_LIBADD = ... $(top_builddir)/common-src/ 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 -rpath /A/p/lib/amanda/perl/auto/Amanda/Device Device.lo ../device-src/ ../common-src/
-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
  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/ -L/usr/lib64 ../device-src/.libs/
../common-src/.libs/ -lm -lreadline
/usr/lib64/ /usr/lib64/
/usr/lib64/ -lrt /usr/lib64/ -lnsl
-lresolv /usr/lib64/ -lssl -lcrypto -ldl -lz  -pthread
-Wl,--export-dynamic -pthread -Wl,-soname -Wl, -o

Looks good:
address@hidden /A/b/perl $ ldd .libs/  | grep libamanda => /A/b/common-src/.libs/

The problem comes when, on 'make install', libtool relinks the library:
 /bin/sh ../libtool --mode=install /usr/bin/install -c  ''
libtool: install: warning: relinking `'
(cd /A/b/perl; /bin/sh ../libtool  --tag=CC --mode=relink gcc
-fno-strict-aliasing -pipe -Wdeclaration-after-statement
-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 -rpath /A/p/lib/amanda/perl/auto/Amanda/Device Device.lo ../device-src/ ../common-src/
-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, -o

And here's where the trouble starts: libtool rewrote
'../common-src/' 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, 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/   | grep
 0x0000000000000001 (NEEDED)             Shared library: []

Consequently, when I try to run the development version in /A/p, 'ld'
looks for; since /A/p/lib/amanda (which is in's RPATH) contains, the search
continues, and it links against the version in /usr/lib.  If I rename
the /A/p/lib/amanda/ to, 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
that can is included the Amanda repository?


Storage Software Engineer

reply via email to

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