You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2005/01/21 01:23:19 UTC
Re: svn commit: r12801 - in trunk/subversion: include libsvn_client
libsvn_ra libsvn_ra_dav libsvn_ra_local libsvn_ra_svn
lundblad@tigris.org writes:
> Author: lundblad
> Date: Thu Jan 20 15:05:59 2005
> New Revision: 12801
>
> New RA API.
>
> If you like reading tons of wrapper functions, if you like API deprecation
> and if you really want to read a somewhat longish commit message, then this
> commit is for you. All others: I warned you.
This change has broken the build on one of my machines. The machine
in question is running a completely standard Debian/testing with
libtool:
ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 220 $
and the build fails with the following error:
cd subversion/clients/cmdline && /bin/sh /home/pm/sw/subversion/obj/libtool --tag=CC --silent --mode=link gcc-3.4 -std=c89 -g -Wall -Wdeclaration-after-statement -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
../../../subversion/libsvn_ra/.libs/libsvn_ra-1.so: undefined reference to `svn_ra_local__init'
../../../subversion/libsvn_ra/.libs/libsvn_ra-1.so: undefined reference to `svn_ra_dav__init'
../../../subversion/libsvn_ra/.libs/libsvn_ra-1.so: undefined reference to `svn_ra_svn__init'
collect2: ld returned 1 exit status
make: *** [subversion/clients/cmdline/svn] Error 1
The build works I if configure with --enable-dso. The build also
works on another machine running a modified Debian/stable with
libtool:
ltmain.sh (GNU libtool) 1.5.2 (1.1220.2.60 2004/01/25 12:25:08) Debian: 192 $
If I pass -v through libtool to gcc I see that the link command for
libtool 1.5.2 explicitly includes the libsvn_ra_{local|dav|svn}-1.so
libraries that provide the missing symbols, while the link command for
libtool 1.5.6 only includes libsvn_ra-1.so.
Is this a libtool bug? I don't really understand exactly how libtool
is supposed to work. Is libtool supposed to link dependent libraries
automatically?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r12801 - in trunk/subversion: include libsvn_client libsvn_ra libsvn_ra_dav libsvn_ra_local libsvn_ra_svn
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, Jan 21, 2005 at 01:56:15PM +0000, Philip Martin wrote:
> I have two sets of libraries installed: Debian's 1.1.1 libraries in
> /usr/lib and the development libraries in $HOME/subversion/lib. The
> build is configured with --prefix=$HOME/subversion. If I remove the
> $HOME/subversion/lib libraries the link works, and the executable that
> results is correctly linked to the build libraries. So it appears
> that it's libraries installed in --prefix that cause the problem.
FWIW, stock GNU libtool operates this way on Darwin. You usually have to
delete the old libs or the linker refuses to link against the new libraries in
your build dir. So, while it seems Debian is explicitly tickling this by
their mods, it operates this way on Darwin all the time.
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r12801 - in trunk/subversion: include libsvn_client
libsvn_ra libsvn_ra_dav libsvn_ra_local libsvn_ra_svn
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Philip Martin <ph...@codematters.co.uk> writes:
>
>> lundblad@tigris.org writes:
>>
>>> Author: lundblad
>>> Date: Thu Jan 20 15:05:59 2005
>>> New Revision: 12801
>>>
>>> New RA API.
>>>
>>> If you like reading tons of wrapper functions, if you like API deprecation
>>> and if you really want to read a somewhat longish commit message, then this
>>> commit is for you. All others: I warned you.
>>
>> This change has broken the build on one of my machines. The machine
>> in question is running a completely standard Debian/testing with
>> libtool:
>>
>> ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 220 $
>
> I have installed a pristine GNU libtool-1.5.6 and the build works.
It took me a while to understand what is going on, but I think I've
got it now. Debian's modified libtool causes the command line client
link to fail because it links against installed libraries rather than
the build libraries. This doesn't happen for libraries explicitly
specified on the command line, so I get the r12801 libsvn_ra, but the
dependent libraries that are not specified explicitly get resolved to
the installed pre-r12801 versions. That explains why the list of
unresolved symbols was so small--only the new symbols were not found.
I have two sets of libraries installed: Debian's 1.1.1 libraries in
/usr/lib and the development libraries in $HOME/subversion/lib. The
build is configured with --prefix=$HOME/subversion. If I remove the
$HOME/subversion/lib libraries the link works, and the executable that
results is correctly linked to the build libraries. So it appears
that it's libraries installed in --prefix that cause the problem.
Comparing the final link commands I see that GNU's libtool generates a
collect2 command that refers to all four RA libraries and specifies
them with a full path to the .so file in the build tree. Debian's
libtool only mentions libsvn_ra-1.so.
Is this a Debian bug? Is this sort of inter-library dependency
supposed to work? I find the libtool documentation confusing.
http://www.gnu.org/software/libtool/manual.html#SEC39 states
that when linking against a libtool library
"you don't need to specify the same `-l' options again: libtool will
do that for you"
but it goes on to say that it doesn't always work and states
"The default, conservative behavior is to avoid linking one library
with another, introducing their inter-dependencies only when a
program is linked with them."
Anyone care to comment?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r12801 - in trunk/subversion: include libsvn_client
libsvn_ra libsvn_ra_dav libsvn_ra_local libsvn_ra_svn
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 22 Jan 2005, Philip Martin wrote:
> > 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:
>
...
> 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
>
...
> 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.
>
That actually answers my question about what happens if you have no
installed libs when building. This has to be a libtool bug IMO.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r12801 - in trunk/subversion: include libsvn_client
libsvn_ra libsvn_ra_dav libsvn_ra_local libsvn_ra_svn
Posted by Philip Martin <ph...@codematters.co.uk>.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> On Fri, 21 Jan 2005, Philip Martin wrote:
>
>> Philip Martin <ph...@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_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
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/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 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
Re: svn commit: r12801 - in trunk/subversion: include libsvn_client
libsvn_ra libsvn_ra_dav libsvn_ra_local libsvn_ra_svn
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Fri, 21 Jan 2005, Philip Martin wrote:
> Philip Martin <ph...@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. How does it
link if you don't have any installed libs? Assuming it find the libs in
the build directory, we have to recommend people to uninstall any previous
install? Even if we didn't add an API, it would use the wrong library
until the new ones are installed over the old.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r12801 - in trunk/subversion: include libsvn_client
libsvn_ra libsvn_ra_dav libsvn_ra_local libsvn_ra_svn
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> lundblad@tigris.org writes:
>
>> Author: lundblad
>> Date: Thu Jan 20 15:05:59 2005
>> New Revision: 12801
>>
>> New RA API.
>>
>> If you like reading tons of wrapper functions, if you like API deprecation
>> and if you really want to read a somewhat longish commit message, then this
>> commit is for you. All others: I warned you.
>
> This change has broken the build on one of my machines. The machine
> in question is running a completely standard Debian/testing with
> libtool:
>
> ltmain.sh (GNU libtool) 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 220 $
I have installed a pristine GNU libtool-1.5.6 and the build works.
Comparing the generated libtool files I see
$ 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
Now I don't pretend to understand libtool, but that diff certainly
look like it has something to do with dependent libraries.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org