Greg Stein <gstein@lyra.org> writes:
> The --rpath will probably have just the "install" directory for those
> libraries. The system doesn't know to look for them in the build areas.
>
> Before the make check, you would need to install the libraries. IOW:
>
> autogen.sh
> ./configure
> make install-lib
> make check
Mmm, two points:
1) It's not good practice for us to require "make install" *before*
"make check". After all, the whole point is that you don't
install something until it passes its own tests, if you're the
cautious type. :-)
2) But anyway, the --rpaths in there actually *are* pointing to
paths in the build area. Because I hadn't issued the "make
install" command yet, but the `svn' client ran, and it obviously
had at least the libsvn_client library loaded, to have gotten as
far as it did. Also, if you actually examine the `--rpath's in
the relink command in the svn pseudo-binary, you can see that
they are pointing to the build area. (See excerpts below.)
Ben's summary of the search algorithm, which I am taking on faith
but which makes sense to me, is this:
rld, the run-time loader, first figures out the dependencies of
the binary -- that is, which shared libraries are needed. Once
it has that list, it looks for them *first* in any `rpath's that
have been built into the binary by ld, then looks in the places
specified by LD_LIBRARY_PATH, and then in some standard system
locations. I might have the order wrong, but the point is that
the search does include the rpath location(s). The whole point
of rpath is so that the binary isn't totally dependent on system
locations and/or an environment variable.
And, in case of doubt, we can check with `ldd'. First, here's the
$relink_command in subversion/clients/cmdline/svn (which is a libtool
shell-script):
relink_command="gcc -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -g -O2 -pthread -I./subversion/include -I. -I./apr/include -I./neon/src -I./expat-lite -I/usr/local/BerkeleyDB.3.2/include -o \$progdir/\$file add-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o delete-cmd.o diff-cmd.o diff.o feedback.o help-cmd.o import-cmd.o main.o propdel-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o status-cmd.o status.o trace-commit.o trace-update.o update-cmd.o util.o revert-cmd.o prompt.o ../../../subversion/libsvn_client/.libs/libsvn_client.so -lm -lcrypt -lnsl -ldl ../../../subversion/libsvn_wc/.libs/libsvn_wc.so -lm -lcrypt -lnsl -ldl ../../../subversion/libsvn_ra/.libs/libsvn_ra.so -lm -lcrypt -lnsl -ldl ../../../subversion/libsvn_delta/.libs/libsvn_delta.so -lm -lcrypt -lnsl -ldl ../../../subversion/libsvn_subr/.libs/libsvn_subr.so -lm -lcrypt -lnsl -ldl /home/kfogel/src/wc_subversion/apr/.libs/libapr.so -lm -lcrypt -lnsl -ldl /home/kfogel/src/w!
c_subversion/apr/shmem/unix/mm/.libs/libmm.so ../../../expat-lite/.libs/libexpat.so -lm -lcrypt -lnsl -ldl -lm -lcrypt -lnsl -ldl -Wl,--rpath -Wl,/home/kfogel/src/wc_subversion/subversion/libsvn_client/.libs -Wl,--rpath -Wl,/home/kfogel/src/wc_subversion/subversion/libsvn_wc/.libs -Wl,--rpath -Wl,/home/kfogel/src/wc_subversion/subversion/libsvn_ra/.libs -Wl,--rpath -Wl,/home/kfogel/src/wc_subversion/subversion/libsvn_delta/.libs -Wl,--rpath -Wl,/home/kfogel/src/wc_subversion/subversion/libsvn_subr/.libs -Wl,--rpath -Wl,/home/kfogel/src/wc_subversion/apr/.libs -Wl,--rpath -Wl,/home/kfogel/src/wc_subversion/apr/shmem/unix/mm/.libs -Wl,--rpath -Wl,/home/kfogel/src/wc_subversion/expat-lite/.libs -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib"
The build area paths are clearly in there, and ldd confirms it:
$ ldd subversion/clients/cmdline/.libs/lt-svn
libsvn_client.so.0 => /home/kfogel/src/wc_subversion/subversion/libsvn_client/.libs/libsvn_client.so.0 (0x40018000)
libm.so.6 => /lib/libm.so.6 (0x40028000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40048000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40075000)
libdl.so.2 => /lib/libdl.so.2 (0x4008c000)
libsvn_wc.so.0 => /home/kfogel/src/wc_subversion/subversion/libsvn_wc/.libs/libsvn_wc.so.0 (0x4008f000)
libsvn_ra.so.0 => /home/kfogel/src/wc_subversion/subversion/libsvn_ra/.libs/libsvn_ra.so.0 (0x400a2000)
libsvn_delta.so.0 => /home/kfogel/src/wc_subversion/subversion/libsvn_delta/.libs/libsvn_delta.so.0 (0x400a5000)
libsvn_subr.so.0 => /home/kfogel/src/wc_subversion/subversion/libsvn_subr/.libs/libsvn_subr.so.0 (0x400ae000)
libapr.so.0 => /home/kfogel/src/wc_subversion/apr/.libs/libapr.so.0 (0x400bb000)
libmm.so.11 => /home/kfogel/src/wc_subversion/apr/shmem/unix/mm/.libs/libmm.so.11 (0x400d6000)
libexpat.so.0 => /home/kfogel/src/wc_subversion/expat-lite/.libs/libexpat.so.0 (0x400db000)
libpthread.so.0 => /lib/libpthread.so.0 (0x400f3000)
libc.so.6 => /lib/libc.so.6 (0x40109000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$
BUT: Notice that libsvn_ra_dav and libsvn_ra_local aren't even
mentioned in that list! Only the generic ra library, libsvn_ra, is
included. So I really think it's a configuration problem -- that
we're simply not linking in ra_dav and ra_local when we do a plain
./configure. They appear to get built, just not linked in... somehow
they're not counted as dependencies?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:35 2006