You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2001/08/07 22:28:02 UTC
build system problem, anyone know how to fix?
At least, I think this is a build system problem... Maybe someone will
know right away what it is?
To reproduce, do
autogen.sh
./configure
make check
... and see basic_tests.py fail when it tries to create a repository
for testing.
If you investigate the failure, you'll see it's because the `svn'
client binary does not know how to handle "file:///" URLs. Why?
Because it doesn't have ra_local loaded (as it happens, it doesn't
have ra_dav either, which would be a problem if we tried to connect to
a remote repository).
If you look at subversion/clients/cmdline/svn, it's a libtool shell
script whose `relink_command' includes `--rpath' commands to link in
all the shared library paths. But those two ra_* libs are missing;
there are no `--rpath' options for them.
Why is this thus? Ben and I do not know. We are hoping someone out
there does. :-)
The reason this problem doesn't usually show up is that we normally
run configure like this:
./configure --enable-maintainer-mode --disable-shared
When you do it that way, the problem doesn't happen.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: build system problem, anyone know how to fix?
Posted by Yoshiki Hayashi <yo...@xemacs.org>.
At Wed, 8 Aug 2001 15:07:39 -0700,
Greg Stein wrote:
>
> On Wed, Aug 08, 2001 at 05:06:37PM -0500, kfogel@collab.net wrote:
> > Greg Stein <gs...@lyra.org> writes:
> > > Yup. Although it will probably be --enable-dso for the switch. The
> > > static/shared would be "link it all in" and the DSO load would be the odd
> > > guy out.
> > >
> > > [ I'm thinking that DSO loading is less useful than shared-lib-linkage ]
> >
> > +1
> >
> > [itching to do it now, but too much other stuff on plate of greater
> > importance :-) ]
>
> (anybody:)
>
> See the SVN_RA_LIB_* values in configure.in.
Here's a patch to add --enable-dso option. Default is to disable DSO.
If both --enable-dso and --disable-shared is present, it prints
warning. It might be better to bomb out instead of warning. You can
change it to whatever you like.
Note that this patch does not solve make check problem with shared
library build. See ldd outputs below. Still, libsvn_ra_dav and
libneon cannot be found. Libtool 1.3.5 doesn't seem to be able to add
dependencies to indirectly linked libraries. (libneon and libsvn_ra_dav
are pulled from libsvn_ra's dependency). I'll try with autconf 2.52
and libtool 1.4 later. I modified build system so that Subversion can
be build with autoconf 2.52 and libtool 1.4 or autoconf 2.13 and
libtool 1.3.5. I didn't have problem to build apr with autoconf 2.52
and libtool 1.4b from Debian sid. I'll send the patch tomorrow since
it might not apply cleanly after applying this and my following patch.
I don't know why libsvn_ra_local is statically linked to libsvn_ra.
Perhaps someone who knows build system better than me can explain it.
$ ldd subversion/clients/cmdline/.libs/lt-svn
libsvn_client.so.0 => /work/yoshiki/work/build/subversion/subversion/libsvn_client/.libs/libsvn_client.so.0 (0x40016000)
libm.so.6 => /lib/libm.so.6 (0x40028000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4004a000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40077000)
libdl.so.2 => /lib/libdl.so.2 (0x4008d000)
libsvn_wc.so.0 => /work/yoshiki/work/build/subversion/subversion/libsvn_wc/.libs/libsvn_wc.so.0 (0x40090000)
libsvn_ra.so.0 => /work/yoshiki/work/build/subversion/subversion/libsvn_ra/.libs/libsvn_ra.so.0 (0x400a3000)
libsvn_ra_dav.so.0 => not found
libneon.so.15 => not found
libdb3.so.3 => /usr/lib/libdb3.so.3 (0x400c5000)
libsvn_delta.so.0 => /work/yoshiki/work/build/subversion/subversion/libsvn_delta/.libs/libsvn_delta.so.0 (0x4016d000)
libsvn_subr.so.0 => /work/yoshiki/work/build/subversion/subversion/libsvn_subr/.libs/libsvn_subr.so.0 (0x40177000)
libapr.so.0 => /work/yoshiki/work/build/subversion/apr/.libs/libapr.so.0 (0x40185000)
libexpat.so.0 => /work/yoshiki/work/build/subversion/expat-lite/.libs/libexpat.so.0 (0x401a1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x401b9000)
libc.so.6 => /lib/libc.so.6 (0x401cf000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libsvn_ra_dav.so.0 => not found
libneon.so.15 => not found
* New option --enable-dso to enable DSO loading.
Defaults to disable.
Index: configure.in
===================================================================
RCS file: /home/penny/cvsroot/subversion/configure.in,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.4.2
diff -u -r1.1.1.1 -r1.1.1.1.4.2
--- configure.in 14 Aug 2001 13:55:34 -0000 1.1.1.1
+++ configure.in 15 Aug 2001 08:32:00 -0000 1.1.1.1.4.2
@@ -267,7 +267,16 @@
fi
dnl decide whether we want to link against the RA libraries
-if test "$enable_shared" = "no"; then
+AC_ARG_ENABLE(dso,
+[ --enable-dso Turn on DSO loading of RA libralies],
+[
+ enable_dso=yes
+ if test "$enable_shared" = "no"; then
+ AC_MSG_WARN([--enable-dso is meaningless with static library build])
+ fi
+])
+
+if test "$enable_shared" = "no" -o "$enable_dso" != "yes"; then
AC_DEFINE(SVN_LIBSVN_CLIENT_LINKS_RA_DAV, 1,
[Defined if libsvn_client should link against libsvn_ra_dav])
SVN_RA_LIB_DEPS="subversion/libsvn_ra_dav/libsvn_ra_dav.la"
--
Yoshiki Hayashi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: build system problem, anyone know how to fix?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Aug 08, 2001 at 05:06:37PM -0500, kfogel@collab.net wrote:
> Greg Stein <gs...@lyra.org> writes:
> > Yup. Although it will probably be --enable-dso for the switch. The
> > static/shared would be "link it all in" and the DSO load would be the odd
> > guy out.
> >
> > [ I'm thinking that DSO loading is less useful than shared-lib-linkage ]
>
> +1
>
> [itching to do it now, but too much other stuff on plate of greater
> importance :-) ]
(anybody:)
See the SVN_RA_LIB_* values in configure.in.
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
Re: build system problem, anyone know how to fix?
Posted by kf...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> Yup. Although it will probably be --enable-dso for the switch. The
> static/shared would be "link it all in" and the DSO load would be the odd
> guy out.
>
> [ I'm thinking that DSO loading is less useful than shared-lib-linkage ]
+1
[itching to do it now, but too much other stuff on plate of greater
importance :-) ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: build system problem, anyone know how to fix?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Aug 08, 2001 at 04:41:17PM -0500, kfogel@collab.net wrote:
> Ahhhhh. I see what you mean, thanks for clarifying -- I was mixed up
> about shared linkage versus run-time dso loading.
>
> So until we do that extra autoconf work to allow us to build a
> complete-but-shared binary, we won't be able to run "make check"
> before "make install" when we build shared. Hmmm. Okay for now,
> needs to be corrected eventually though.
Yup. Although it will probably be --enable-dso for the switch. The
static/shared would be "link it all in" and the DSO load would be the odd
guy out.
[ I'm thinking that DSO loading is less useful than shared-lib-linkage ]
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
Re: build system problem, anyone know how to fix?
Posted by kf...@collab.net.
Ahhhhh. I see what you mean, thanks for clarifying -- I was mixed up
about shared linkage versus run-time dso loading.
So until we do that extra autoconf work to allow us to build a
complete-but-shared binary, we won't be able to run "make check"
before "make install" when we build shared. Hmmm. Okay for now,
needs to be corrected eventually though.
-K
Greg Stein <gs...@lyra.org> writes:
> 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
Re: build system problem, anyone know how to fix?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Aug 08, 2001 at 12:04:54PM -0500, kfogel@collab.net wrote:
> Greg Stein <gs...@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
Re: build system problem, anyone know how to fix?
Posted by kf...@collab.net.
Greg Stein <gs...@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
Re: build system problem, anyone know how to fix?
Posted by Greg Stein <gs...@lyra.org>.
The underlying problem is locating shared libraries. "Where are they?"
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
With more work, we could set up LD_LIBRARY_PATH to point to all the various
directories, prior to testing. Another alternative would be to create a
subdirectory, from the top, to hold the libraries during a test phase. Most
Perl programs build locally and test against that before installation.
Note: this is only dealing with shared libs (note that --disable-shared
succeeds simply because the libs are linked into "svn", so there is no
searching for them). I'm not sure how Perl deals with shared libs when it
builds/tests, if at all.
Cheers,
-g
On Tue, Aug 07, 2001 at 05:28:02PM -0500, kfogel@collab.net wrote:
> At least, I think this is a build system problem... Maybe someone will
> know right away what it is?
>
> To reproduce, do
>
> autogen.sh
> ./configure
> make check
>
> ... and see basic_tests.py fail when it tries to create a repository
> for testing.
>
> If you investigate the failure, you'll see it's because the `svn'
> client binary does not know how to handle "file:///" URLs. Why?
> Because it doesn't have ra_local loaded (as it happens, it doesn't
> have ra_dav either, which would be a problem if we tried to connect to
> a remote repository).
>
> If you look at subversion/clients/cmdline/svn, it's a libtool shell
> script whose `relink_command' includes `--rpath' commands to link in
> all the shared library paths. But those two ra_* libs are missing;
> there are no `--rpath' options for them.
>
> Why is this thus? Ben and I do not know. We are hoping someone out
> there does. :-)
>
> The reason this problem doesn't usually show up is that we normally
> run configure like this:
>
> ./configure --enable-maintainer-mode --disable-shared
>
> When you do it that way, the problem doesn't happen.
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
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