You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Hülsmann <e....@gmx.net> on 2003/08/10 12:31:02 UTC
lt-svnversion consistenly linked against wrong libs (was: Re:
svnversion_tests.py: lt-svnversion uses wrong libraries)
Ok, back with more results. I am able to consistenly build lt-svnversion against the wrong libaries, so I decided to make a report as complete as I can.
The problem:
the program subversion/svnversion/.libs/lt-svnversion is linked against (some - not all) libsvn_* libraries in the /usr/local/lib directory instead of the ones in the build tree.
The following output demonstrates the problem I describe:
After building (using 'make') and executing 'subversion/svnversion/svnversion' (to let libtool do its job), I get the following output when running:
$ ldd subversion/svnversion/.libs/lt-svnversion | grep -v '.libs/' | grep 'libsvn_'
libsvn_ra_svn-1.so.0 => /usr/local/lib/libsvn_ra_svn-1.so.0 (0x402fd000)
libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0 (0x40306000)
libsvn_diff-1.so.0 => /usr/local/lib/libsvn_diff-1.so.0 (0x4030d000)
libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0 (0x40312000)
This problem only occurs to svnversion; not to any of the other svn programs in the tree.
My build environment:
- RedHat 8.0
- libtool 1.4.2 (dated Nov 2001), upgraded to libtool 1.5 (dated Apr 14th 2003)
- autoconf 2.53
- automake 2.53
- gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
- GNU ld version 2.13.90.0.2 20020802
the contents of the /usr/local/lib directory:
/usr/local/lib/libneon.so
/usr/local/lib/libneon.so.23
/usr/local/lib/libneon.so.23.0.9
/usr/local/lib/libsvn_client-1.so
/usr/local/lib/libsvn_client-1.so.0
/usr/local/lib/libsvn_client-1.so.0.0.0
/usr/local/lib/libsvn_delta-1.so
/usr/local/lib/libsvn_delta-1.so.0
/usr/local/lib/libsvn_delta-1.so.0.0.0
/usr/local/lib/libsvn_diff-1.so
/usr/local/lib/libsvn_diff-1.so.0
/usr/local/lib/libsvn_diff-1.so.0.0.0
/usr/local/lib/libsvn_fs-1.so
/usr/local/lib/libsvn_fs-1.so.0
/usr/local/lib/libsvn_fs-1.so.0.0.0
/usr/local/lib/libsvn_ra-1.so
/usr/local/lib/libsvn_ra-1.so.0
/usr/local/lib/libsvn_ra-1.so.0.0.0
/usr/local/lib/libsvn_ra_dav-1.so
/usr/local/lib/libsvn_ra_dav-1.so.0
/usr/local/lib/libsvn_ra_dav-1.so.0.0.0
/usr/local/lib/libsvn_ra_local-1.so
/usr/local/lib/libsvn_ra_local-1.so.0
/usr/local/lib/libsvn_ra_local-1.so.0.0.0
/usr/local/lib/libsvn_ra_svn-1.so
/usr/local/lib/libsvn_ra_svn-1.so.0
/usr/local/lib/libsvn_ra_svn-1.so.0.0.0
/usr/local/lib/libsvn_repos-1.so
/usr/local/lib/libsvn_repos-1.so.0
/usr/local/lib/libsvn_repos-1.so.0.0.0
/usr/local/lib/libsvn_subr-1.so
/usr/local/lib/libsvn_subr-1.so.0
/usr/local/lib/libsvn_subr-1.so.0.0.0
/usr/local/lib/libsvn_wc-1.so
/usr/local/lib/libsvn_wc-1.so.0
/usr/local/lib/libsvn_wc-1.so.0.0.0
/usr/local/lib/libxml2.so
/usr/local/lib/libxml2.so.2
/usr/local/lib/libxml2.so.2.4.23
Using the build script below in a directory without a 'svn'-subdirectory, I have consistenly been able to get an incorrectly linked lt-svnversion with both libtool version 1.4.2 and 1.5. Just to be complete, I inserted the ldd dumps for lt-svn, lt-svnadmin and lt-svnlook as well as the one for lt-svnversion.
Does anybody have any idea what to do next? Or maybe, given these data: can anybody reproduce this problem?
bye,
Erik.
---------------- complete ldd dump
# ldd subversion/svnversion/.libs/lt-svnversion
libsvn_client-1.so.0 => /home/erik/svn/subversion/libsvn_client/.libs/libsvn_client-1.so.0 (0x40015000)
libsvn_wc-1.so.0 => /home/erik/svn/subversion/libsvn_wc/.libs/libsvn_wc-1.so.0 (0x4002c000)
libsvn_ra-1.so.0 => /home/erik/svn/subversion/libsvn_ra/.libs/libsvn_ra-1.so.0 (0x40048000)
libsvn_ra_local-1.so.0 => /home/erik/svn/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so.0 (0x4004b000)
libsvn_repos-1.so.0 => /home/erik/svn/subversion/libsvn_repos/.libs/libsvn_repos-1.so.0 (0x40050000)
libsvn_fs-1.so.0 => /home/erik/svn/subversion/libsvn_fs/.libs/libsvn_fs-1.so.0 (0x40060000)
libdb-4.0.so => /lib/libdb-4.0.so (0x4008b000)
libsvn_ra_dav-1.so.0 => /home/erik/svn/subversion/libsvn_ra_dav/.libs/libsvn_ra_dav-1.so.0 (0x40133000)
libneon.so.23 => /home/erik/svn/neon/src/.libs/libneon.so.23 (0x40142000)
libssl.so.2 => /lib/libssl.so.2 (0x4015a000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x4018b000)
libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x4025f000)
libsvn_ra_svn-1.so.0 => /usr/local/lib/libsvn_ra_svn-1.so.0 (0x402fd000)
libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0 (0x40306000)
libsvn_diff-1.so.0 => /usr/local/lib/libsvn_diff-1.so.0 (0x4030d000)
libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0 (0x40312000)
libaprutil-0.so.0 => /home/erik/svn/apr-util/.libs/libaprutil-0.so.0 (0x40332000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40346000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4034d000)
libapr-0.so.0 => /home/erik/svn/apr/.libs/libapr-0.so.0 (0x4036d000)
librt.so.1 => /lib/librt.so.1 (0x40389000)
libm.so.6 => /lib/i686/libm.so.6 (0x4039b000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x403be000)
libnsl.so.1 => /lib/libnsl.so.1 (0x403eb000)
libdl.so.2 => /lib/libdl.so.2 (0x40401000)
libz.so.1 => /usr/lib/libz.so.1 (0x40404000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40412000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
---------------- complete ldd dump
# ldd subversion/clients/cmdline/.libs/lt-svn
libsvn_client-1.so.0 => /home/erik/svn/subversion/libsvn_client/.libs/libsvn_client-1.so.0 (0x40015000)
libsvn_wc-1.so.0 => /home/erik/svn/subversion/libsvn_wc/.libs/libsvn_wc-1.so.0 (0x4002c000)
libsvn_ra-1.so.0 => /home/erik/svn/subversion/libsvn_ra/.libs/libsvn_ra-1.so.0 (0x40048000)
libsvn_diff-1.so.0 => /home/erik/svn/subversion/libsvn_diff/.libs/libsvn_diff-1.so.0 (0x4004b000)
libsvn_ra_local-1.so.0 => /home/erik/svn/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so.0 (0x40051000)
libsvn_repos-1.so.0 => /home/erik/svn/subversion/libsvn_repos/.libs/libsvn_repos-1.so.0 (0x40055000)
libsvn_fs-1.so.0 => /home/erik/svn/subversion/libsvn_fs/.libs/libsvn_fs-1.so.0 (0x40065000)
libdb-4.0.so => /lib/libdb-4.0.so (0x40090000)
libsvn_ra_dav-1.so.0 => /home/erik/svn/subversion/libsvn_ra_dav/.libs/libsvn_ra_dav-1.so.0 (0x40138000)
libsvn_ra_svn-1.so.0 => /home/erik/svn/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.so.0 (0x40147000)
libsvn_delta-1.so.0 => /home/erik/svn/subversion/libsvn_delta/.libs/libsvn_delta-1.so.0 (0x40151000)
libsvn_subr-1.so.0 => /home/erik/svn/subversion/libsvn_subr/.libs/libsvn_subr-1.so.0 (0x40158000)
libaprutil-0.so.0 => /home/erik/svn/apr-util/.libs/libaprutil-0.so.0 (0x40177000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4018b000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40192000)
libapr-0.so.0 => /home/erik/svn/apr/.libs/libapr-0.so.0 (0x401b2000)
librt.so.1 => /lib/librt.so.1 (0x401cf000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x401e1000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4020e000)
libdl.so.2 => /lib/libdl.so.2 (0x40224000)
libneon.so.23 => /home/erik/svn/neon/src/.libs/libneon.so.23 (0x40227000)
libssl.so.2 => /lib/libssl.so.2 (0x4023f000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x40270000)
libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x40344000)
libm.so.6 => /lib/i686/libm.so.6 (0x403e2000)
libz.so.1 => /usr/lib/libz.so.1 (0x40404000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40412000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
---------------- complete ldd dump
# ldd subversion/svnadmin/.libs/lt-svnadmin
libsvn_repos-1.so.0 => /home/erik/svn/subversion/libsvn_repos/.libs/libsvn_repos-1.so.0 (0x40015000)
libsvn_fs-1.so.0 => /home/erik/svn/subversion/libsvn_fs/.libs/libsvn_fs-1.so.0 (0x40025000)
libsvn_delta-1.so.0 => /home/erik/svn/subversion/libsvn_delta/.libs/libsvn_delta-1.so.0 (0x40041000)
libdb-4.0.so => /lib/libdb-4.0.so (0x40057000)
libsvn_subr-1.so.0 => /home/erik/svn/subversion/libsvn_subr/.libs/libsvn_subr-1.so.0 (0x400ff000)
libaprutil-0.so.0 => /home/erik/svn/apr-util/.libs/libaprutil-0.so.0 (0x4011e000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40133000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4013a000)
libapr-0.so.0 => /home/erik/svn/apr/.libs/libapr-0.so.0 (0x4015a000)
librt.so.1 => /lib/librt.so.1 (0x40176000)
libm.so.6 => /lib/i686/libm.so.6 (0x40188000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x401aa000)
libnsl.so.1 => /lib/libnsl.so.1 (0x401d8000)
libdl.so.2 => /lib/libdl.so.2 (0x401ee000)
libz.so.1 => /usr/lib/libz.so.1 (0x401f1000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x401ff000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
---------------- complete ldd dump
# ldd subversion/svnlook/.libs/lt-svnlook
libsvn_repos-1.so.0 => /home/erik/svn/subversion/libsvn_repos/.libs/libsvn_repos-1.so.0 (0x40015000)
libsvn_fs-1.so.0 => /home/erik/svn/subversion/libsvn_fs/.libs/libsvn_fs-1.so.0 (0x40025000)
libsvn_delta-1.so.0 => /home/erik/svn/subversion/libsvn_delta/.libs/libsvn_delta-1.so.0 (0x40041000)
libdb-4.0.so => /lib/libdb-4.0.so (0x40057000)
libsvn_diff-1.so.0 => /home/erik/svn/subversion/libsvn_diff/.libs/libsvn_diff-1.so.0 (0x400ff000)
libsvn_subr-1.so.0 => /home/erik/svn/subversion/libsvn_subr/.libs/libsvn_subr-1.so.0 (0x40104000)
libaprutil-0.so.0 => /home/erik/svn/apr-util/.libs/libaprutil-0.so.0 (0x40124000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40138000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4013f000)
libapr-0.so.0 => /home/erik/svn/apr/.libs/libapr-0.so.0 (0x4015f000)
librt.so.1 => /lib/librt.so.1 (0x4017b000)
libm.so.6 => /lib/i686/libm.so.6 (0x4018d000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x401b0000)
libnsl.so.1 => /lib/libnsl.so.1 (0x401dd000)
libdl.so.2 => /lib/libdl.so.2 (0x401f3000)
libz.so.1 => /usr/lib/libz.so.1 (0x401f6000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40204000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
---------------- end of dump list
---------------- build script
#!/bin/bash
do_step ()
{
echo "$@"
$@
if [ ! $? ]; then
echo "error: $?; $!"
exit
fi
}
if [ "$1" == "--no-tests" ]; then
no_tests=1
fi
if [ -e svn ]; then
do_step cd svn/apr
do_step cvs update
do_step cd ../apr-util
do_step cvs update
do_step cd ..
do_step svn update
else
do_step svn co http://svn.collab.net/repos/svn/trunk svn
do_step cd svn
do_step cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co apr
do_step cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co apr-util
do_step wget http://www.webdav.org/neon/neon-0.23.9.tar.gz
do_step tar xvzf neon-0.23.9.tar.gz
do_step mv neon{-0.23.9,}
fi
do_step ./autogen.sh
CFLAGS='-O2 -pipe' LDLFAGS=-s \
./configure --with-zlib --disable-static --with-ssl
if [ ! $? ]; then
echo "Error running configure!"
exit
fi
# how to do the above configure / if steps within do_step?
do_step make clean
do_step make
# create lt-svnversion
subversion/svnversion/svnversion
if [ -n "$(ldd subversion/svnversion/.libs/lt-svnversion | grep -v '.libs/' | grep libsvn )" ]; then
echo "FAIL: svnversion incorrectly linked against existing libraries"
exit
fi
if [ ! $no_tests ]; then
do_step make check-clean
do_step make check CLEANUP=1
fi
echo "Run su -c 'make install'"
---------------- end of build script
>>I think I have used 1.4.2 in the past with no problems, but I don't have the
>>exact version string. I'm using 1.4.3 at the moment.
>
>[snip]
>
>>The link command explicitly mentions the build tree versions of all
>>the libraries that are wrongly located, I would expect it to work. I
>>don't know why it doesn't, perhaps some sort of RPATH problem. You
>>can see the RPATH by using things like
>
>Now that I know that the programs in the build dirs are stub scripts,
>I decided to look into the one for svnversion. The relink command
>contains the incorrectly linked libs after an -L/usr/local/lib argument.
>That could be a problem, since looking in /usr/local/lib will get a(n)
>(old) version of a library by the same name.
>
>> objdump -x subversion/libsvn_client/.libs/libsvn_client-1.so | grep RPATH
>> objdump -x subversion/svnversion/.libs/lt-svnversion | grep RPATH
>
>Will do this later. see below.
>
>>> After running the make command *all* libraries point to /usr/local and
>>> the contents of the .libs directory is empty.
>>
>>Huh? Which .libs is empty?
>
>The one for subversion/svnversion/.libs
>
>In the meantime I try to set up my box to do all tests on a ramdisk just
>as you have reported it to work on this list earlier. Makes a lot of difference
>on the disk activity, but I don't seem able to find the lt-* programs any more.
>
>I will rebuild in-tree again and mail back with the rest of my progress.
>
>>> When I have run
>>> make check CLEANUP=1 TESTS=3Dsubversion/tests/clients/cmdline/svnversion_tests.py
>
>>> the .libs directories is not empty anymore and the ldd command says
>>> that libraries are linked agains the versions in my build tree
>>> again.
>>
>>I'm confused--do you mean that all the libraries are found in the
>>build tree? Has the problem been solved?
>
>No, the problem has not been solved - unfortunately. I did not understand how
>libtool works, but what I was seeing was the effect of the svnversion stub rewriting
>the links to the libraries.
>
>[snip: explanation of libtool guts ]
>
>Ok. as said, I will rebuild all of it in the tree and report back what happens.
>
>
>bye,
>
>
>Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs (was: Re: svnversion_tests.py: lt-svnversion uses wrong libraries)
Posted by e....@gmx.net.
Hi!
I will send the libtool commands tomorrow (I'm about to go to bed now)
but the problem occurs with either version of libtool: first I has 1.4.2 and
in an attempt to eliminate the problem, I upgraded to 1.5. They both
exhibit the same problem.
bye,
Erik.
> Erik Hülsmann wrote:
> > Ok, back with more results. I am able to consistenly build
> > lt-svnversion against the wrong libaries, so I decided to make a
> > report as complete as I can.
> >
> > The problem:
> > the program subversion/svnversion/.libs/lt-svnversion is linked
> > against (some - not all) libsvn_* libraries in the /usr/local/lib
> > directory instead of the ones in the build tree.
> >
> > The following output demonstrates the problem I describe:
> >
> > After building (using 'make') and executing
> > 'subversion/svnversion/svnversion' (to let libtool do its job), I get
> > the following output when running:
> >
> > $ ldd subversion/svnversion/.libs/lt-svnversion | grep -v '.libs/' |
> > grep 'libsvn_' libsvn_ra_svn-1.so.0 =>
> > /usr/local/lib/libsvn_ra_svn-1.so.0 (0x402fd000)
> > libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0
> > (0x40306000) libsvn_diff-1.so.0 =>
> > /usr/local/lib/libsvn_diff-1.so.0 (0x4030d000) libsvn_subr-1.so.0 =>
> > /usr/local/lib/libsvn_subr-1.so.0 (0x40312000)
> >
> > This problem only occurs to svnversion; not to any of the other svn
> > programs in the tree.
>
> Maybe removing the --silent flag to libtool from the Makefile would reveal
> some anomaly in the generated gcc command?
>
> > My build environment:
> > - RedHat 8.0
> > - libtool 1.4.2 (dated Nov 2001), upgraded to libtool 1.5 (dated Apr
> > 14th 2003)
>
> So... which version? 1.5? Or do you suspect that there may still be bits
> of
> 1.4.2 lurking on your system?
>
> Max.
>
--
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs (was: Re: svnversion_tests.py: lt-svnversion uses wrong libraries)
Posted by Max Bowsher <ma...@ukf.net>.
Erik Hülsmann wrote:
> Ok, back with more results. I am able to consistenly build
> lt-svnversion against the wrong libaries, so I decided to make a
> report as complete as I can.
>
> The problem:
> the program subversion/svnversion/.libs/lt-svnversion is linked
> against (some - not all) libsvn_* libraries in the /usr/local/lib
> directory instead of the ones in the build tree.
>
> The following output demonstrates the problem I describe:
>
> After building (using 'make') and executing
> 'subversion/svnversion/svnversion' (to let libtool do its job), I get
> the following output when running:
>
> $ ldd subversion/svnversion/.libs/lt-svnversion | grep -v '.libs/' |
> grep 'libsvn_' libsvn_ra_svn-1.so.0 =>
> /usr/local/lib/libsvn_ra_svn-1.so.0 (0x402fd000)
> libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0
> (0x40306000) libsvn_diff-1.so.0 =>
> /usr/local/lib/libsvn_diff-1.so.0 (0x4030d000) libsvn_subr-1.so.0 =>
> /usr/local/lib/libsvn_subr-1.so.0 (0x40312000)
>
> This problem only occurs to svnversion; not to any of the other svn
> programs in the tree.
Maybe removing the --silent flag to libtool from the Makefile would reveal
some anomaly in the generated gcc command?
> My build environment:
> - RedHat 8.0
> - libtool 1.4.2 (dated Nov 2001), upgraded to libtool 1.5 (dated Apr
> 14th 2003)
So... which version? 1.5? Or do you suspect that there may still be bits of
1.4.2 lurking on your system?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs
Posted by Erik Hülsmann <e....@gmx.net>.
>>Erik H�lsmann <e....@gmx.net> writes:
>>
>>> [ snip ]
>>>
>>>>I think the problem is the -L/usr/local/lib that comes before -lssl.
>>>>
>>>>Have a look in the libtool file
>>>> /home/erik/svn/subversion/libsvn_ra_dav/libsvn_ra_dav-1.la
>>>>Is the -L/usr/local/lib there?
>>>
>>> Yes, there is, but libssl.so.2 is located in /lib and libssl.so in
>>> /usr/lib so there is no reason for the command to be there.
>>
>>I don't think it's ssl, I suspect it is the way neon links to libxml,
>>try
>>
>> grep NEON_LIBS Makefile
>>
> # grep NEON_LIBS Makefile
>NEON_LIBS = $(abs_builddir)/neon/src/libneon.la -L/usr/local/lib -lssl -lcrypto -lz -L/usr/local/lib -lxml2 -lz -lm
>
BTW:
# locate xml2.so
/usr/lib/libxml2.so.2
/usr/lib/libxml2.so.2.4.23
/usr/local/lib/libxml2.so.2.4.23
/usr/local/lib/libxml2.so.2
/usr/local/lib/libxml2.so
So then eliminating /usr/local/lib/libxml2* should eliminate my problems? It would not be my favorate solution though, since the problem in the build script remains.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs
Posted by Erik Hülsmann <e....@gmx.net>.
Hi Philip!
Thanks for your continued help!
[ snip ]
>> So what now?!
>
>So the problem is that
>
> neon-config --libs
>
>includes -L/usr/local/lib which causes problems for subsequent
>Subversion libraries.
# neon-config --libs
-L/usr/local/lib -lneon -lssl -lcrypto -lz -L/usr/local/lib -lxml2 -lz -lm
So I guess you're right.
>It's odd that svn doesn't have the same problem, I suspect some
>reordering within the the gen-make system. If you edit build.conf and
>compare the [svn] and [svnversion] sections they have different libs
>lines. You could try replacing the svnversion line with that from
>svn, then run ./gen-make.py in the source directory, run config.nice
>in the build directory, make clean and and finally make.
I saw your other post about the $(NEON_LIBS), so I decided to do that.
I think I will be running the above test too, but I am running the rebuild
now and will report back to the list when I come back from work; this evening.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> reordering within the the gen-make system. If you edit build.conf and
> compare the [svn] and [svnversion] sections they have different libs
> lines. You could try replacing the svnversion line with that from
> svn, then run ./gen-make.py in the source directory, run config.nice
> in the build directory, make clean and and finally make.
Ooops, no need to rerun configure. Just run ./gen-make.py in the
source directory, make clean and make.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs
Posted by Philip Martin <ph...@codematters.co.uk>.
Erik Hülsmann <e....@gmx.net> writes:
> # grep NEON_LIBS Makefile
> NEON_LIBS = $(abs_builddir)/neon/src/libneon.la -L/usr/local/lib -lssl -lcrypto -lz -L/usr/local/lib -lxml2 -lz -lm
>
> So what now?!
So the problem is that
neon-config --libs
includes -L/usr/local/lib which causes problems for subsequent
Subversion libraries.
It's odd that svn doesn't have the same problem, I suspect some
reordering within the the gen-make system. If you edit build.conf and
compare the [svn] and [svnversion] sections they have different libs
lines. You could try replacing the svnversion line with that from
svn, then run ./gen-make.py in the source directory, run config.nice
in the build directory, make clean and and finally make.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs
Posted by Erik Hülsmann <e....@gmx.net>.
>Erik H�lsmann <e....@gmx.net> writes:
>
>> [ snip ]
>>
>>>I think the problem is the -L/usr/local/lib that comes before -lssl.
>>>
>>>Have a look in the libtool file
>>> /home/erik/svn/subversion/libsvn_ra_dav/libsvn_ra_dav-1.la
>>>Is the -L/usr/local/lib there?
>>
>> Yes, there is, but libssl.so.2 is located in /lib and libssl.so in
>> /usr/lib so there is no reason for the command to be there.
>
>I don't think it's ssl, I suspect it is the way neon links to libxml,
>try
>
> grep NEON_LIBS Makefile
>
# grep NEON_LIBS Makefile
NEON_LIBS = $(abs_builddir)/neon/src/libneon.la -L/usr/local/lib -lssl -lcrypto -lz -L/usr/local/lib -lxml2 -lz -lm
So what now?!
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs
Posted by Philip Martin <ph...@codematters.co.uk>.
Erik Hülsmann <e....@gmx.net> writes:
> [ snip ]
>
>>I think the problem is the -L/usr/local/lib that comes before -lssl.
>>
>>Have a look in the libtool file
>> /home/erik/svn/subversion/libsvn_ra_dav/libsvn_ra_dav-1.la
>>Is the -L/usr/local/lib there?
>
> Yes, there is, but libssl.so.2 is located in /lib and libssl.so in
> /usr/lib so there is no reason for the command to be there.
I don't think it's ssl, I suspect it is the way neon links to libxml,
try
grep NEON_LIBS Makefile
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs (was: Re:
svnversion_tests.py: lt-svnversion uses wrong libraries)
Posted by Erik Hülsmann <e....@gmx.net>.
[ snip ]
>I think the problem is the -L/usr/local/lib that comes before -lssl.
>
>Have a look in the libtool file
> /home/erik/svn/subversion/libsvn_ra_dav/libsvn_ra_dav-1.la
>Is the -L/usr/local/lib there?
Yes, there is, but libssl.so.2 is located in /lib and libssl.so in
/usr/lib so there is no reason for the command to be there. How
do I make sure that the -L/usr/local/lib does not appear in that
file anymore!?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs (was: Re:
svnversion_tests.py: lt-svnversion uses wrong libraries)
Posted by Philip Martin <ph...@codematters.co.uk>.
Erik Hülsmann <e....@gmx.net> writes:
> cd subversion/svnversion && /bin/sh /home/erik/svn/libtool --mode=link gcc -O2 -pipe -pthread -DNEON_ZLIB -DNEON_SSL -rpath /usr/local/lib -o svnversion main.o ../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_ra_svn/libsvn_ra_svn-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_diff/libsvn_diff-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /home/erik/svn/apr-util/libaprutil-0.la -lgdbm -ldb-4.0 -lexpat /home/erik/svn/apr/libapr-0.la -lrt -lm -lcrypt -lnsl -ldl -lz
> gcc -O2 -pipe -pthread -DNEON_ZLIB -DNEON_SSL -o .libs/svnversion main.o ../../subversion/libsvn_client/.libs/libsvn_client-1.so /home/erik/svn/subversion/libsvn_wc/.libs/libsvn_wc-1.so /home/erik/svn/subversion/libsvn_ra/.libs/libsvn_ra-1.so /home/erik/svn/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so /home/erik/svn/subversion/libsvn_repos/.libs/libsvn_repos-1.so /home/erik/svn/subversion/libsvn_fs/.libs/libsvn_fs-1.so -ldb /home/erik/svn/subversion/libsvn_ra_dav/.libs/libsvn_ra_dav-1.so /home/erik/svn/neon/src/.libs/libneon.so -L/usr/local/lib -lssl -lcrypto /usr/local/lib/libxml2.so /home/erik/svn/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.so /home/erik/svn/subversion/libsvn_diff/.libs/libsvn_diff-1.so ../../subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.so /home/erik/svn/subversion/libsvn_delta/.libs/libsvn_delta-1.so ../../subversion/libsvn_delta/.libs/libsvn_delta-1.so ../../subversion/libsvn_diff/.libs/libsvn_diff-1.so /home/erik/svn/subversion/libsvn_subr/.libs/libsvn_subr-1.so ../../subversion/libsvn_subr/.libs/libsvn_subr-1.so /home/erik/svn/apr-util/.libs/libaprutil-0.so /usr/lib/libgdbm.so /usr/lib/libdb-4.0.so /usr/lib/libexpat.so /home/erik/svn/apr/.libs/libapr-0.so -lrt -lm -lcrypt -lnsl -ldl -lz -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/apr/lib
> creating svnversion
I think the problem is the -L/usr/local/lib that comes before -lssl.
Have a look in the libtool file
/home/erik/svn/subversion/libsvn_ra_dav/libsvn_ra_dav-1.la
Is the -L/usr/local/lib there?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs (was: Re:
svnversion_tests.py: lt-svnversion uses wrong libraries)
Posted by Erik Hülsmann <e....@gmx.net>.
>Erik H�lsmann <e....@gmx.net> writes:
>
>> The problem:
>> the program subversion/svnversion/.libs/lt-svnversion is linked against (some - not all) libsvn_* libraries in the /usr/local/lib directory instead of the ones in the build tree.
>>
>> The following output demonstrates the problem I describe:
>>
>> After building (using 'make') and executing 'subversion/svnversion/svnversion' (to let libtool do its job), I get the following output when running:
>>
>> $ ldd subversion/svnversion/.libs/lt-svnversion | grep -v '.libs/' | grep 'libsvn_'
>> libsvn_ra_svn-1.so.0 => /usr/local/lib/libsvn_ra_svn-1.so.0 (0x402fd000)
>> libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0 (0x40306000)
>> libsvn_diff-1.so.0 => /usr/local/lib/libsvn_diff-1.so.0 (0x4030d000)
>> libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0 (0x40312000)
>>
>> This problem only occurs to svnversion; not to any of the other svn programs in the tree.
>Try running
>
>LD_DEBUG=libs subversion/svnversion/svnversion
>
>to get some debug output from the shared library loader.
The information from the shared library loader indicates the effects
to be expected from the output of the objdump command below.
>Examining the RPATH embedded in the executable and the libraries may
>help, use objdump:
>
>objdump -x subversion/svnversion/.libs/lt-svnversion | grep RPATH
>objdump -x subversion/libsvn_client/.libs/libsvn_client-1.so | grep RPATH
the output of the objdump command is given below (actual output is one line!)
# objdump -x subversion/svnversion/.libs/lt-svnversion | grep RPATH
RPATH /home/erik/svn/subversion/libsvn_client/.libs:
/home/erik/svn/subversion/libsvn_wc/.libs:
/home/erik/svn/subversion/libsvn_ra/.libs:
/home/erik/svn/subversion/libsvn_ra_local/.libs:
/home/erik/svn/subversion/libsvn_repos/.libs:
/home/erik/svn/subversion/libsvn_fs/.libs:
/home/erik/svn/subversion/libsvn_ra_dav/.libs:
/home/erik/svn/neon/src/.libs:
/usr/local/lib:
/home/erik/svn/subversion/libsvn_ra_svn/.libs:
/home/erik/svn/subversion/libsvn_diff/.libs:
/home/erik/svn/subversion/libsvn_delta/.libs:
/home/erik/svn/subversion/libsvn_subr/.libs:
/home/erik/svn/apr-util/.libs:
/home/erik/svn/apr/.libs:
/usr/local/apr/lib
To see if the libtool command also contains the /usr/local/lib in the middle
of the list of libsvn_* libraries, I executed the command:
# make LTFLAGS=
which gave as output (3 lines actual output):
cd subversion/svnversion && /bin/sh /home/erik/svn/libtool --mode=link gcc -O2 -pipe -pthread -DNEON_ZLIB -DNEON_SSL -rpath /usr/local/lib -o svnversion main.o ../../subversion/libsvn_client/libsvn_client-1.la ../../subversion/libsvn_ra_svn/libsvn_ra_svn-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_diff/libsvn_diff-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /home/erik/svn/apr-util/libaprutil-0.la -lgdbm -ldb-4.0 -lexpat /home/erik/svn/apr/libapr-0.la -lrt -lm -lcrypt -lnsl -ldl -lz
gcc -O2 -pipe -pthread -DNEON_ZLIB -DNEON_SSL -o .libs/svnversion main.o ../../subversion/libsvn_client/.libs/libsvn_client-1.so /home/erik/svn/subversion/libsvn_wc/.libs/libsvn_wc-1.so /home/erik/svn/subversion/libsvn_ra/.libs/libsvn_ra-1.so /home/erik/svn/subversion/libsvn_ra_local/.libs/libsvn_ra_local-1.so /home/erik/svn/subversion/libsvn_repos/.libs/libsvn_repos-1.so /home/erik/svn/subversion/libsvn_fs/.libs/libsvn_fs-1.so -ldb /home/erik/svn/subversion/libsvn_ra_dav/.libs/libsvn_ra_dav-1.so /home/erik/svn/neon/src/.libs/libneon.so -L/usr/local/lib -lssl -lcrypto /usr/local/lib/libxml2.so /home/erik/svn/subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.so /home/erik/svn/subversion/libsvn_diff/.libs/libsvn_diff-1.so ../../subversion/libsvn_ra_svn/.libs/libsvn_ra_svn-1.so /home/erik/svn/subversion/libsvn_delta/.libs/libsvn_delta-1.so ../../subversion/libsvn_delta/.libs/libsvn_delta-1.so ../../subversion/libsvn_diff/.libs/libsvn_diff-1.so /home/erik/svn/subversion/libsvn_subr
/.libs/libsvn_subr-1.so ../../subversion/libsvn_subr/.libs/libsvn_subr-1.so /home/erik/svn/apr-util/.libs/libaprutil-0.so /usr/lib/libgdbm.so /usr/lib/libdb-4.0.so /usr/lib/libexpat.so /home/erik/svn/apr/.libs/libapr-0.so -lrt -lm -lcrypt -lnsl -ldl -lz -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/apr/lib
creating svnversion
I have no idea what the output from libtool means with respect to resolving this problem though.
I figure this is a problem within the link stage of the program, maybe with the arguments from libtool for gcc?
Philip, do you know what my next step could be?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: lt-svnversion consistenly linked against wrong libs (was: Re:
svnversion_tests.py: lt-svnversion uses wrong libraries)
Posted by Philip Martin <ph...@codematters.co.uk>.
Erik Hülsmann <e....@gmx.net> writes:
> The problem:
> the program subversion/svnversion/.libs/lt-svnversion is linked against (some - not all) libsvn_* libraries in the /usr/local/lib directory instead of the ones in the build tree.
>
> The following output demonstrates the problem I describe:
>
> After building (using 'make') and executing 'subversion/svnversion/svnversion' (to let libtool do its job), I get the following output when running:
>
> $ ldd subversion/svnversion/.libs/lt-svnversion | grep -v '.libs/' | grep 'libsvn_'
> libsvn_ra_svn-1.so.0 => /usr/local/lib/libsvn_ra_svn-1.so.0 (0x402fd000)
> libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0 (0x40306000)
> libsvn_diff-1.so.0 => /usr/local/lib/libsvn_diff-1.so.0 (0x4030d000)
> libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0 (0x40312000)
>
> This problem only occurs to svnversion; not to any of the other svn programs in the tree.
Try running
LD_DEBUG=libs subversion/svnversion/svnversion
to get some debug output from the shared library loader.
Examining the RPATH embedded in the executable and the libraries may
help, use objdump:
objdump -x subversion/svnversion/.libs/lt-svnversion | grep RPATH
objdump -x subversion/libsvn_client/.libs/libsvn_client-1.so | grep RPATH
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org