[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: Greg Stein <gstein_at_lyra.org>
Date: 2001-08-08 23:17:52 CEST

On Wed, Aug 08, 2001 at 12:04:54PM -0500, kfogel@collab.net wrote:
> 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. :-)

Yah. I got to this point later in my note. But I see the problem now...

> 2) But anyway, the --rpaths in there actually *are* pointing to
> paths in the build area. Because I hadn't issued the "make

Ah. Good.

[ I probably did that on purpose for the new build stuff, but simply forgot.
  Those --rpath things are needed for the code to run at all. ]

>...
> 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.

Yup.

>...
> $ 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?

They are *not* supposed to be in there. That is entirely correct.

The libraries are dynamically loaded when needed. We don't depend upon the
run-time link loader to do it (we make explicit calls).

So... either install them, or set your LD_LIBRARY_PATH.

The alternative is some more configuration work. Essentially, there are
three ways for us to deal with the ra_* libraries:

1) link them all in, statically
2) link them all in, as shared libs
3) load them as shared libs

Our current system implements (1) and (3). You were expecting (2), which we
don't have without some autoconf stuff to allow selecting between 2 and 3
when shared libs are built.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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.