On Wed, Dec 28, 2011 at 12:29:25AM +0100, Elias Pipping wrote:
> Hello,
>
> I get a couple of test failures with subversion 1.7.2; using the trunk
> instead does not help.
>
> Here are the test failures:
>
> Running tests in db-test [7/85]FAILURE
> Running tests in entries-compat-test [10/85]FAILURE
> Running tests in op-depth-test [17/85]FAILURE
> Running tests in pristine-store-test [21/85]FAILURE
> Running tests in tree-conflict-data-test [34/85]FAILURE
> Running tests in authz_tests.py [37/85][SKIPPED] Python sqlite3 module required
>
> Let me take just one of those tests, db-test:
>
> % python ./build/run_tests.py --config-file ./subversion/tests/tests.conf . . subversion/tests/libsvn_wc/db-test
> Running tests in db-test [1/1]FAILURE
> At least one test FAILED, checking /home/pipping/subversion-1.7.2/tests.log
> FAIL: db-test: Unknown test failure; see tests.log.
> Summary of test results:
> 1 test FAILED
> %
>
> A look at the log file reveals:
>
> % < tests.log
> START: db-test
> /home/pipping/subversion-1.7.2/subversion/tests/libsvn_wc/.libs/db-test: symbol lookup error: /home/pipping/subversion
> -1.7.2/subversion/tests/libsvn_wc/.libs/db-test: undefined symbol: svn_io_remove_file2
> FAIL: db-test: Unknown test failure; see tests.log.
> END: db-test
> ELAPSED: db-test 0:00:00.106494
>
> %
>
> And indeed, running the test manually yields:
>
> % libtool --mode execute ./subversion/tests/libsvn_wc/db-test
> /home/pipping/subversion-1.7.2/subversion/tests/libsvn_wc/.libs/db-test: symbol lookup error: /home/pipping/subversion-1.7.2/subversion/tests/libsvn_wc/.libs/db-test: undefined symbol: svn_io_remove_file2
> %
>
> That symbol is there, however.
>
> This happens if I set the LD_LIBRARY_PATH correctly (the way libtool
> --mode execute should):
>
> % LD_LIBRARY_PATH=./subversion/libsvn_wc/.libs/:./subversion/libsvn_subr/.libs:./subversion/tests/.libs ./subversion/tests/libsvn_wc/.libs/db-test
> PASS: db-test 1: get information from wc.db
> PASS: db-test 2: insert different nodes into wc.db
> PASS: db-test 3: getting the list of BASE or WORKING children
> PASS: db-test 4: reading information about the WORKING tree
> PASS: db-test 5: creation of per-directory handles
> PASS: db-test 6: scanning added working nodes
> PASS: db-test 7: deletion introspection functions
> PASS: db-test 8: relocating a node
> PASS: db-test 9: work queue processing
> PASS: db-test 10: externals store
> %
>
> Here's what libtool sets LD_LIBRARY_PATH to:
>
> % grep LD_LIBRARY_PATH=\" ./subversion/tests/libsvn_wc/db-test
> LD_LIBRARY_PATH="/home/pipping/subversion-1.7.2/subversion/libsvn_client/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_wc/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_ra/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_ra_local/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_ra_svn/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_ra_neon/.libs:/usr/lib64:/home/pipping/subversion-1.7.2/subversion/tests/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_repos/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_fs/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_fs_fs/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_fs_util/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_delta/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_diff/.libs:/home/pipping/subversion-1.7.2/subversion/libsvn_subr/.libs:$LD_LIBRARY_PATH"
> %
>
> Given how hard to read that is, here's that string again with colons
> replaced by newlines:
>
> /home/pipping/subversion-1.7.2/subversion/libsvn_client/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_wc/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_ra/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_ra_local/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_ra_svn/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_ra_neon/.libs
> /usr/lib64
> /home/pipping/subversion-1.7.2/subversion/tests/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_repos/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_fs/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_fs_fs/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_fs_util/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_delta/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_diff/.libs
> /home/pipping/subversion-1.7.2/subversion/libsvn_subr/.libs
> $LD_LIBRARY_PATH
>
> The problem is with /usr/lib64. That is where an old version of
> subversion (1.6.17) lives. Removing /usr/lib64 from that string makes
> the db-test pass. Consequently, the aforementioned problem occurs if an
> old version of subversion is installed and vanishes immediately once
> that version is uninstalled.
>
> This is clearly not desirable -- had I had e.g. subversion 1.7.1
> installed instead of 1.6.17, I take it the tests would've passed,
> fooling me into thinking what I had built had passed its tests when in
> fact they'd never been run.
>
>
> Best regards,
>
> Elias Pipping
This is an inherent problem with using and managing shared libraries
on a computer system.
Note that the problem may be transitive, i.e. SVN depends on some
library A at /usr/local/lib/A which in turn depends on a library B
residing at /usr/lib64/B. This will cause Subversion to be linked
with both -L/usr/local/lib and -L/usr/lib64 (these linker arguments are
computed by libtool, which is an external component the SVN build system
is using and which we have no direct control over).
Later, when svn is actually run, the ld.so program also tries to locate
the needed set of shared libraries in both /usr/local/lib and /usr/lib64.
So if there is also a library C (in your example, C is libsvn_subr),
possibly in different versions, at both /usr/local/lib/C and at /usr/lib64/C,
which C will be linked to depends on whichever combination of libraries
the compile and runtime linkers are picking.
There is no good way for us to fix the problem for you because
the behaviour of compile and run-time linkers is OS-dependent.
Use binary packages provided by your operating system vendor or learn how
to properly compile programs using shared libraries on your operating system.
As you've just found out, having similar and possibly conflicting sets of
shared libraries in distinct search paths is simply not a good idea if
the compile and run-time linkers are going to be using both of these
search paths.
Here's example 'ldd' output of my development trunk svn build, on OpenBSD
(see https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/unix-build).
Note that it uses no library from /usr/local/lib because otherwise
I couldn't install a subversion binary package shipped by OpenBSD
(which installs svn libraries in /usr/local/lib, so I need to avoid
having -L/usr/local/lib in my build). Else, I couldn't be sure
which code is being tested when I run the tests.
/home/stsp/svn/prefix/svn-trunk/bin/svn:
Start End Type Open Ref GrpRef Name
0000000000400000 0000000000844000 exe 1 0 0 /home/stsp/svn/prefix/svn-trunk/bin/svn
0000000205468000 00000002058e2000 rlib 0 1 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_client-1.so.0.0
0000000202b74000 000000020303c000 rlib 0 2 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_wc-1.so.0.0
00000002049a5000 0000000204db3000 rlib 0 2 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_ra-1.so.0.0
000000020b53b000 000000020b945000 rlib 0 3 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_ra_local-1.so.0.0
0000000204381000 00000002047bc000 rlib 0 4 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_repos-1.so.0.0
000000020fcec000 00000002100f6000 rlib 0 5 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_fs-1.so.0.0
000000020ce14000 000000020d250000 rlib 0 6 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_fs_fs-1.so.0.0
000000020ac82000 000000020b0bd000 rlib 0 6 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_fs_base-1.so.0.0
00000002033ca000 00000002037cc000 rlib 0 8 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_fs_util-1.so.0.0
000000020a440000 000000020a85f000 rlib 0 3 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_ra_svn-1.so.0.0
000000020a00f000 000000020a42f000 rlib 0 4 0 /home/stsp/svn/prefix/cyrus-sasl/lib/libsasl2.so.2.23
000000020843e000 000000020886c000 rlib 0 3 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_ra_neon-1.so.0.0
000000020c830000 000000020cc65000 rlib 0 3 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_ra_serf-1.so.0.0
00000002058e2000 0000000205cfa000 rlib 0 4 0 /home/stsp/svn/prefix/serf/lib/libserf-1.so.0.0
000000020bb18000 000000020c0d6000 rlib 0 9 0 /home/stsp/svn/prefix/bdb/lib/libdb-4.7.so
0000000203f6b000 0000000204381000 rlib 0 12 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_delta-1.so.0.0
000000020f6f2000 000000020fb08000 rlib 0 3 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_diff-1.so.0.0
000000020e02d000 000000020e4a2000 rlib 0 15 0 /home/stsp/svn/prefix/svn-trunk/lib/libsvn_subr-1.so.0.0
000000020c0e7000 000000020c59f000 rlib 0 16 0 /home/stsp/svn/prefix/sqlite/lib/libsqlite3.so.8.6
000000020a85f000 000000020ac82000 rlib 0 16 0 /home/stsp/svn/prefix/libmagic/lib/libmagic.so.1.0
00000002093f1000 0000000209815000 rlib 0 17 0 /home/stsp/svn/prefix/apr/lib/libaprutil-1.so.3.12
0000000207f19000 0000000208421000 rlib 0 18 0 /home/stsp/svn/prefix/iconv/lib/libiconv.so.7.0
0000000206e77000 00000002072aa000 rlib 0 18 0 /home/stsp/svn/prefix/apr/lib/libapr-1.so.4.5
0000000204db3000 00000002051e3000 rlib 0 4 0 /home/stsp/svn/prefix/neon/lib/libneon.so.29.6
0000000201d78000 000000020218d000 rlib 0 19 0 /usr/lib/libz.so.4.1
000000020e4a2000 000000020e8fd000 rlib 0 7 0 /usr/lib/libssl.so.17.0
0000000208d0a000 0000000209122000 rlib 0 5 0 /usr/lib/libgssapi.so.5.0
0000000207720000 0000000207bbe000 rlib 0 9 0 /usr/lib/libkrb5.so.18.0
000000020886c000 0000000208d0a000 rlib 0 1 0 /usr/lib/libasn1.so.18.0
00000002037cc000 0000000203d67000 rlib 0 7 0 /usr/lib/libcrypto.so.20.0
0000000201954000 0000000201d78000 rlib 0 19 0 /usr/lib/libexpat.so.9.0
000000020259a000 0000000202a81000 rlib 0 1 0 /usr/lib/libc.so.61.0
0000000209c00000 0000000209c00000 rtld 0 1 0 /usr/libexec/ld.so
Received on 2011-12-29 17:21:52 CET