[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: build system problem, anyone know how to fix?

From: <kfogel_at_collab.net>
Date: 2001-08-08 19:04:54 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.