Package: libtool
Version: 1.5.6-3
Severity: normal

*** Please type your report below this line ***
Sorry this is so long, a quick summary: Debian's libtool appears to resolve
inter-library dependencies to the install tree rather than the build tree,
this is different from the upstream GNU behaviour and can be awkward for
people using Debian as a development platform.

I am building Subversion from upstream source on a Debian machine with
libtool 1.5.6-3 installed.  Subversion builds a number of shared libraries
and executables and I have configured my Subversion build using
--prefix=$HOME/subversion so shared libraries get installed in
$HOME/subversion/lib.

One of libraries built is libsvn_ra-1.so, it is linked as follows:

cd subversion/libsvn_ra && /bin/sh /home/pm/sw/subversion/obj2/libtool --tag=CC 
--silent --mode=link gcc  -std=c89 -g -Wall -Wsign-compare -Wwrite-strings 
-Wpointer-arith -Wshadow -Wmissing-prototypes -Wstrict-prototypes 
-Wmissing-declarations -Wendif-labels -Wredundant-decls -DSVN_DEBUG 
-DSVN_DEBUG_ERROR -g -pthread -DNEON_ZLIB -DNEON_SSL    -rpath 
/home/pm/subversion/lib -o libsvn_ra-1.la  ra_loader.lo 
../../subversion/libsvn_subr/libsvn_subr-1.la 
../../subversion/libsvn_ra_local/libsvn_ra_local-1.la 
../../subversion/libsvn_repos/libsvn_repos-1.la 
../../subversion/libsvn_fs/libsvn_fs-1.la 
../../subversion/libsvn_delta/libsvn_delta-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la 
../../subversion/libsvn_ra_svn/libsvn_ra_svn-1.la 
../../subversion/libsvn_delta/libsvn_delta-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la 
../../subversion/libsvn_ra_dav/libsvn_ra_dav-1.la 
../../subversion/libsvn_delta/libsvn_delta-1.la 
../../subversion/libsvn_subr/libsvn_subr-1.la 
/home/pm/apache/lib/libaprutil-0.la -ldb -lexpat 
/home/pm/apache/lib/libapr-0.la -lrt -lm -lcrypt -lnsl  -lpthread -ldl

In particular, it links against three other libraries in the build tree
namely, libsvn_ra_svn-1.la, libsvn_ra_dav-1.la and libsvn_ra_local-1.la.

libsvn_ra-1.la is then used when linking an executable as follows:

cd subversion/clients/cmdline && /bin/sh /home/pm/sw/subversion/obj2/libtool 
--tag=CC --silent --mode=link gcc  -std=c89 -g -Wall -Wsign-compare 
-Wwrite-strings -Wpointer-arith -Wshadow -Wmissing-prototypes 
-Wstrict-prototypes -Wmissing-declarations -Wendif-labels -Wredundant-decls 
-DSVN_DEBUG -DSVN_DEBUG_ERROR -g -pthread -DNEON_ZLIB -DNEON_SSL    -rpath 
/home/pm/subversion/lib -o svn  add-cmd.o blame-cmd.o cat-cmd.o checkout-cmd.o 
cleanup-cmd.o commit-cmd.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o 
help-cmd.o import-cmd.o info-cmd.o log-cmd.o ls-cmd.o main.o merge-cmd.o 
mkdir-cmd.o move-cmd.o notify.o prompt.o propdel-cmd.o propedit-cmd.o 
propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolved-cmd.o revert-cmd.o 
status-cmd.o status.o switch-cmd.o update-cmd.o util.o 
../../../subversion/libsvn_client/libsvn_client-1.la 
../../../subversion/libsvn_wc/libsvn_wc-1.la 
../../../subversion/libsvn_ra/libsvn_ra-1.la 
../../../subversion/libsvn_delta/libsvn_delta-1.la 
../../../subversion/libsvn_subr/libsvn_subr-1.la 
/home/pm/apache/lib/libaprutil-0.la -ldb -lexpat 
/home/pm/apache/lib/libapr-0.la -lrt -lm -lcrypt -lnsl  -lpthread -ldl -lneon 
-lssl -lcrypto -lz -lxml2 -lz -lpthread -lm

Note that this is explicitly linked against libsvn_ra-1.la but there is no
mention of the three dependent libraries.

If I pass -v through libtool to gcc then I get the link command:

 /usr/lib/gcc-lib/i486-linux/3.3.5/collect2 --eh-frame-hdr -m elf_i386 
-dynamic-linker /lib/ld-linux.so.2 -o .libs/svn 
/usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o 
/usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o 
/usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o 
-L/usr/lib/gcc-lib/i486-linux/3.3.5 
-L/usr/lib/gcc-lib/i486-linux/3.3.5/../../.. add-cmd.o blame-cmd.o cat-cmd.o 
checkout-cmd.o cleanup-cmd.o commit-cmd.o copy-cmd.o delete-cmd.o diff-cmd.o 
export-cmd.o help-cmd.o import-cmd.o info-cmd.o log-cmd.o ls-cmd.o main.o 
merge-cmd.o mkdir-cmd.o move-cmd.o notify.o prompt.o propdel-cmd.o 
propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o 
resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o update-cmd.o 
util.o ../../../subversion/libsvn_client/.libs/libsvn_client-1.so 
../../../subversion/libsvn_wc/.libs/libsvn_wc-1.so 
../../../subversion/libsvn_ra/.libs/libsvn_ra-1.so 
../../../subversion/libsvn_delta/.libs/libsvn_delta-1.so 
../../../subversion/libsvn_subr/.libs/libsvn_subr-1.so 
/home/pm/apache/lib/libaprutil-0.so -ldb /usr/lib/libexpat.so 
/home/pm/apache/lib/libapr-0.so -lrt -lcrypt -lnsl -ldl /usr/lib/libneon.so 
-lssl -lcrypto /usr/lib/libxml2.so -lz -lpthread -lm --rpath 
/home/pm/subversion/lib --rpath /home/pm/apache/lib -lgcc --as-needed -lgcc_s 
--no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed 
/usr/lib/gcc-lib/i486-linux/3.3.5/crtend.o 
/usr/lib/gcc-lib/i486-linux/3.3.5/../../../crtn.o

This mentions libsvn_ra-1.so but doesn't mention the three dependent
libraries, however the link normally succeeds whether or not I have
libraries installed in $HOME/subversion/lib.  Running ldd on the binary
in the build tree reveals that it is correctly linked to libraries in
the build tree, and once installed it is correctly linked to libraries
in the install tree.

A recent change to the Subversion source (revision 12801) introduced
new functions into the three dependent libraries, and made
libsvn_ra-1.so reference those new functions.  Now the link fails
citing unresolved symbols corresponding to the new functions (and only
the new functions not any of the old functions).  If I remove the
installed libraries the link works.  This seems to indicate that the
link is resolving the dependent libraries to those in the install
tree, which don't have the new functions, rather than those in the
build tree.  Quite how it does that I don't know, perhaps it uses the
NEEDED data form the ELF header and -rpath passed on the command line.

If I reconfigure my build to use a pristine GNU 1.5.6 libtool the link no
longer fails.  I have examined the generated libsvn_ra-1.la files and they
are identical (modulo the libtool version comment).  The generated libtool
scripts are different:

$ diff libtool.gnu libtool.debian
316c316
< link_all_deplibs=unknown
---
> link_all_deplibs=no
390c390
< TIMESTAMP=" (1.1220.2.94 2004/04/10 16:27:27)"
---
> TIMESTAMP=" (1.1220.2.95 2004/04/11 05:50:42) Debian$Rev: 220 $"
2184c2184,2187
<       link) libs="$deplibs %DEPLIBS% $dependency_libs" ;;
---
>       link)
>         libs="$deplibs %DEPLIBS%"
>         test "X$link_all_deplibs" != Xno && libs="$libs $dependency_libs"
>         ;;
2210,2213d2212
<         if test "$pass" = conv; then
<           deplibs="$deplib $deplibs"
<           continue
<         fi
3275a3275,3279
>         *)
>           $echo "$modename: unknown library version type \`$version_type'" 
> 1>&2
>           $echo "Fatal configuration error.  See the $PACKAGE docs for more 
> information." 1>&2
>           exit $EXIT_FAILURE
>           ;;
7034c7038
< link_all_deplibs=unknown
---
> link_all_deplibs=no

and while the libtool invocation is the same, GNU libtool generates a
different final link command:

 /usr/lib/gcc-lib/i486-linux/3.3.5/collect2 --eh-frame-hdr -m elf_i386 
-dynamic-linker /lib/ld-linux.so.2 -o .libs/svn 
/usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o 
/usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o 
/usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o 
-L/usr/lib/gcc-lib/i486-linux/3.3.5 
-L/usr/lib/gcc-lib/i486-linux/3.3.5/../../.. add-cmd.o blame-cmd.o cat-cmd.o 
checkout-cmd.o cleanup-cmd.o commit-cmd.o copy-cmd.o delete-cmd.o diff-cmd.o 
export-cmd.o help-cmd.o import-cmd.o info-cmd.o log-cmd.o ls-cmd.o main.o 
merge-cmd.o mkdir-cmd.o move-cmd.o notify.o prompt.o propdel-cmd.o 
propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o 
resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o update-cmd.o 
util.o ../../../subversion/libsvn_client/.libs/libsvn_client-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_wc/.libs/libsvn_wc-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_ra/.libs/libsvn_ra-1.so 
../../../subversion/libsvn_wc/.libs/libsvn_wc-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_diff/.libs/libsvn_diff-1.so 
../../../subversion/libsvn_ra/.libs/libsvn_ra-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so
 /home/pm/sw/subversion/obj2/subversion/libsvn_repos/.libs/libsvn_repos-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_fs/.libs/libsvn_fs-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_fs_fs/.libs/libsvn_fs_fs-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_fs_base/.libs/libsvn_fs_base-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_ra_dav/.libs/libsvn_ra_dav-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_delta/.libs/libsvn_delta-1.so 
../../../subversion/libsvn_delta/.libs/libsvn_delta-1.so 
/home/pm/sw/subversion/obj2/subversion/libsvn_subr/.libs/libsvn_subr-1.so 
../../../subversion/libsvn_subr/.libs/libsvn_subr-1.so 
/home/pm/apache/lib/libaprutil-0.so -ldb /usr/lib/libexpat.so 
/home/pm/apache/lib/libapr-0.so -lrt -lcrypt -lnsl -ldl /usr/lib/libneon.so 
-lssl -lcrypto /usr/lib/libxml2.so -lz -lpthread -lm --rpath 
/home/pm/subversion/lib --rpath /home/pm/apache/lib -lgcc --as-needed -lgcc_s 
--no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed 
/usr/lib/gcc-lib/i486-linux/3.3.5/crtend.o 
/usr/lib/gcc-lib/i486-linux/3.3.5/../../../crtn.o

Note that this explicitly refers to the build tree for the three dependent
libraries, I guess that explains why it works.

I find the libtool inter-library documentation confusing, but I think this
is a Debian bug simply because Debian's libtool fails and GNU's libtool
appears to work.  Is there some reason that Debian's libtool is not allowed
to work the same way as GNU's libtool (rpath perhaps)?  I have another
machine with Debian libtool 1.5.2-1 installed and that doesn't show the
problem, it works like GNU libtool.

One final point: while investigating this I grabbed the Debian source for
libtool 1.5.6-3 and I was surprised to see that libtool is a native package,
with a .tar.gz rather than an .orig.tar.gz and a .diff.gz.  Does libtool
really qualify to be a native package?  It makes it harder to determine 
the differences between Debian and upstream.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)

Versions of packages libtool depends on:
ii  autotools-dev               20041130.2   Update infrastructure for config.{
ii  cpp                         4:3.3.5-1    The GNU C preprocessor (cpp)
ii  file                        4.12-1       Determines file type using "magic"
ii  gcc [c-compiler]            4:3.3.5-1    The GNU C compiler
ii  gcc-3.3 [c-compiler]        1:3.3.5-5    The GNU C compiler
ii  gcc-3.4 [c-compiler]        3.4.3-6      The GNU C compiler
ii  libc6-dev [libc-dev]        2.3.2.ds1-20 GNU C Library: Development Librari

-- no debconf information

Reply via email to