Re: svn commit: r12801 - in trunk/subversion: include libsvn_client libsvn_ra libsvn_ra_dav libsvn_ra_local libsvn_ra_svn

"Peter N. Lundblad" <peter@famlundblad.se> writes:

> On Fri, 21 Jan 2005, Philip Martin wrote:
>
>> Philip Martin <philip@codematters.co.uk> writes:
>>
>>
>> Now I don't pretend to understand libtool, but that diff certainly
>> look like it has something to do with dependent libraries.
>>
> I saw your next mail of the reason for this, but I deleted that:-(
>
> I run Debian stable with libtool 1.4.2a and it works for me.

I haven't used 1.4.2a for a while, it works with Debian's 1.5.2 and
with GNU's 1.5.6.

> How does it link if you don't have any installed libs?

I'm not sure I understand your question. This is the libtool link command:

cd subversion/clients/cmdline && /bin/sh /home/pm/sw/subversion/obj/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_sub
r-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
If I add a -v to that the underlying link command is displayed:

/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/p
m/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 it references libsvn_ra-1.so in the build tree and no other RA
libs (if I use a pristine GNU 1.5.6 it references all four RA
libraries in the build tree).

There are unresolved symbols in libsvn_ra-1.so

$ nm subversion/libsvn_ra/.libs/libsvn_ra-1.so|grep _init
00001168 T _init
         U svn_ra_dav_init
         U svn_ra_dav__init
00001ca0 T svn_ra_init_ra_libs
         U svn_ra_local_init
         U svn_ra_local__init
         U svn_ra_svn_init
         U svn_ra_svn__init

and it refers to the other RA libs (although that's simply a function
of the NEEDED and RPATH information in the ELF headers):

$ ldd subversion/libsvn_ra/.libs/libsvn_ra-1.so | grep svn_ra
        libsvn_ra_local-1.so.0 => /home/pm/sw/subversion/obj/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so.0 (0x40006000)
        libsvn_ra_svn-1.so.0 => /home/pm/sw/subversion/obj/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.so.0 (0x40026000)
        libsvn_ra_dav-1.so.0 => /home/pm/sw/subversion/obj/subversion/libsvn_ra_dav/.libs/libsvn_ra_dav-1.so.0 (0x40035000)

The failing link only reports the new __init symbols and not the old
_init ones. I can only explain that if it's using the installed
libraries at link time; the fact that removing the installed libraries
makes it work tends to support the idea.

How does it happen? I don't know. I suppose collect2 could combine
the NEEDED values in the ELF header of libsvn_ra-1.so with the -rpath
to the install directory passed on the command line, but that's just a
guess.

Once linked the executable depends on all the RA libraries in the
build tree:

$ ldd subversion/clients/cmdline/.libs/lt-svn | grep svn_ra
        libsvn_ra-1.so.0 => /home/pm/sw/subversion/obj/subversion/libsvn_ra/.libs/libsvn_ra-1.so.0 (0x40041000)
        libsvn_ra_local-1.so.0 => /home/pm/sw/subversion/obj/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so.0 (0x400b9000)
        libsvn_ra_svn-1.so.0 => /home/pm/sw/subversion/obj/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.so.0 (0x400da000)
        libsvn_ra_dav-1.so.0 => /home/pm/sw/subversion/obj/subversion/libsvn_ra_dav/.libs/libsvn_ra_dav-1.so.0 (0x400e8000)

Once installed the binary is linked to libraries in the install tree:

$ ldd ~/subversion/bin/svn | grep svn_ra
        libsvn_ra-1.so.0 => /home/pm/subversion/lib/libsvn_ra-1.so.0 (0x40041000)
        libsvn_ra_local-1.so.0 => /home/pm/subversion/lib/libsvn_ra_local-1.so.0 (0x400b7000)
        libsvn_ra_svn-1.so.0 => /home/pm/subversion/lib/libsvn_ra_svn-1.so.0 (0x400d8000)
        libsvn_ra_dav-1.so.0 => /home/pm/subversion/lib/libsvn_ra_dav-1.so.0 (0x400e6000)

The pristine GNU 1.5.6 doesn't have the problem so it's a Debian
problem. I've reported it to submit@bugs.debian.org but the bug
hasn't shown up yet (the machine in question has "awkward" net access
so email wasn't original fully configured and the first report
bounced, I don't know what's happened to the second report).

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org