Another strange discovery: if you ever built shared, and did a 'make
install'... you get a bunch of libsvn_* libraries in /usr/local/lib.
If you then try to --disable-shared and rebuild statically, sure
enough, all the .a files are rebuilt, but in the *final* link, libtool
somehow detects the shared libs still sitting in /usr/local/lib, and
links shared anyway!
I wasn't able to link statically until I removed the shared libs from
my system.
This is either a huge annoyance in libtool, or we're just using it
incorrectly.
Mo DeJong <mdejong@cygnus.com> writes:
> I did some more looking at the problem with the
> build being broken when you pass --disable-shared
> to subversion's configure script. The problem
> seems to be libtool's fault. It would appear
> that the current "solution" is to only allow
> shared builds, which is a real bummer for
> ease of debugging.
>
> >From notes/dav_setup.txt
>
> Note: do *not* configure subversion with "--disable-shared"!
> mod_dav_svn *must* be built as a shared library.
>
> Note: it *is* possible to build mod_dav_svn as a static library
> and link it directly into Apache. Possible, but painful. Stick
> with the shared library for now; if you can't, then ask.
>
>
>
> Removing the hack in libsvn_ra_dav/Makefile.am and
> libsvn_ra_local/Makefile.am fixes the static
> build at a cost of apparently breaking the
> shared build.
>
>
> Index: libsvn_ra_dav/Makefile.am
> ===================================================================
> RCS file: /cvs/subversion/subversion/libsvn_ra_dav/Makefile.am,v
> retrieving revision 1.9
> diff -u -r1.9 Makefile.am
> --- libsvn_ra_dav/Makefile.am 2001/03/28 11:51:29 1.9
> +++ libsvn_ra_dav/Makefile.am 2001/04/01 06:05:52
> @@ -10,7 +10,7 @@
> ### shared libs are being built. libtool barfs on us. we need to upgrade
> ### to libtool 1.4 when it gets released
> libsvn_ra_dav_la_LIBADD = \
> - -L$(top_builddir)/neon/src/.libs -lneon
> + -L$(top_builddir)/neon/src -lneon
>
> INCLUDES = @SVN_INCLUDES@ @SVN_APR_INCLUDES@ @SVN_NEON_INCLUDES@
>
> Index: libsvn_ra_local/Makefile.am
> ===================================================================
> RCS file: /cvs/subversion/subversion/libsvn_ra_local/Makefile.am,v
> retrieving revision 1.6
> diff -u -r1.6 Makefile.am
> --- libsvn_ra_local/Makefile.am 2001/03/27 11:59:15 1.6
> +++ libsvn_ra_local/Makefile.am 2001/04/01 06:05:52
> @@ -14,9 +14,9 @@
> ### shared libs are being built. libtool barfs on us. we need to upgrade
> ### to libtool 1.4 when it gets released
> libsvn_ra_local_la_LIBADD = \
> - -L$(top_builddir)/subversion/libsvn_fs/.libs -lsvn_fs \
> - -L$(top_builddir)/subversion/libsvn_delta/.libs -lsvn_delta \
> - -L$(top_builddir)/subversion/libsvn_subr/.libs -lsvn_subr
> + -L$(top_builddir)/subversion/libsvn_fs -lsvn_fs \
> + -L$(top_builddir)/subversion/libsvn_delta -lsvn_delta \
> + -L$(top_builddir)/subversion/libsvn_subr -lsvn_subr
>
> ## Build flags ---------
>
>
>
> So what are our options:
>
> 1. Leave it the way it is, perhaps add an error
> if the user passes --disable-shared.
>
> 2. Add automake conditional var like SVN_STATIC
> that gets set to true when you pass --disable-shared
> to configure. There is already a IS_STATIC_APACHE
> automake conditional, but it does not seem to work.
>
> 3. Upgrade to the CVS version of libtool, since the
> comments would seem to imply this would remove
> the need for the workarounds.
>
> Option 1 really stinks. I think the most simple
> approach is 2, but 3 might be the best idea in
> the long run. Option 3 would require that
> developers have the CVS versions of
> autoconf, automake, and perhaps libtool.
> Keep in mind that option 3 would present
> more of a "challenge", since it would
> require getting apr to sign on to the idea.
>
> Opinions?
>
> Mo DeJong
> Red Hat Inc
Received on Sat Oct 21 14:36:27 2006