You should compile your own apache2 from the tarball provided on
subversion website. This includes appropriate apr/apr-util stuff. Things
should work much better that way..
TTimo
On Thu, 16 Jan 2003 15:18:28 -0500
Greg Ward <gward@mems-exchange.org> wrote:
> I've had a hell of a time trying to build Subversion on Debian unstable.
> (Yes, I know it's already packaged -- in fact I'm using the packaged
> version daily already. But I'm trying to improve some bug reports I
> filed yesterday by compiling with debug info.)
>
> I eventually got it to build using the subversion-r4276 (0.16.1)
> tarball, but it wasn't easy. (I did try checking out the latest code,
> but the configure script didn't even run to completion.
>
> The following is partly venting, partly implicit suggestions for
> improvements in the configure script and/or build docs, and partly to
> help anyone else who might be having similar problems.
>
> I have the following relevant Debian packages installed:
>
> libapr0 2.0.43-1
> libapr0-dev 2.0.43-1
> libneon23 0.23.5-2
> libneon23-dev 0.23.5-2
> libdb4.0 4.0.14-1
> libdb4.0-dev 4.0.14-1
> libdb4.0-util 4.0.14-1
>
> Attempt #1: just run "./configure" without trying to point out any of
> the above libs -- see how well it does without help. configure runs
> fine, although it doesn't find Debian's DB4 library -- no big deal, I
> think, all I want for now is a client build.
>
> This build fails when linking with the local copy of apr-util:
>
> [...]
> cd subversion/tests/libsvn_subr && /bin/sh /scratch/downloads/subversion-r4276/libtool --silent --mode=link gcc -g -O2 -pthread -DNEON_ZLIB -rpath /usr/local/lib -o hashdump-test hashdump-test.o ../../../subversion/tests/libsvn_test-1.la ../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../subversion/libsvn_subr/libsvn_subr-1.la /scratch/downloads/subversion-r4276/apr-util/libaprutil-0.la -lgdbm -ldb -lexpat /scratch/downloads/subversion-r4276/apr/libapr-0.la -lm -lcrypt -lnsl -ldl
> /scratch/downloads/subversion-r4276/apr-util/.libs/libaprutil-0.so: undefined reference to `db_create'
> /scratch/downloads/subversion-r4276/apr-util/.libs/libaprutil-0.so: undefined reference to `db_strerror'
>
> Poking around a bit, the dependency seems to come from
> apr-util/dbm/apr_dbm_berkeleydb.c . Why is this being built if
> configure couldn't find Berkeley DB in the first place?
>
> Attempt #2: at first I thought this was a problem building apr-util, so
> I decided to just use Debian's libapr, ie. "./configure --with-apr=/usr
> --with-apr-util=/usr". (The libapr0 package includes both
> libapr.so.0.9.2 and libaprutil.so.0.9.2.) Looks like Debian's libapr is
> too old for Subversion, but now that I'm re-reading the INSTALL file, I
> see this was doomed to fail: "This release of Subversion requires an
> httpd, APR, and APRUTIL more advanced than the latest public releases."
> Sigh. Chalk this one up to pilot error.
>
> Attempt #3: since the failure of attempt #1 appears to be due to the
> lack of Berkeley DB, and I already have DB 4.0.14 courtesy of Debian,
> I might as well tell configure where it is:
> ./configure --with-berkeley-db=/usr
>
> This should work, as <db.h> and -ldb are both clearly DB 4.0.14:
>
> $ ls -l /usr/include/db.h
> -rw-r--r-- 1 root root 70359 2002-04-23 03:14 /usr/include/db.h
> $ grep DB_VERSION /usr/include/db.h
> #define DB_VERSION_MAJOR 4
> #define DB_VERSION_MINOR 0
> #define DB_VERSION_PATCH 14
> #define DB_VERSION_STRING "Sleepycat Software: Berkeley DB 4.0.14: (April 23, 2002)"
>
> $ ll /usr/lib/libdb.{a,so}
> lrwxrwxrwx 1 root root 11 2003-01-15 18:29 /usr/lib/libdb.a -> libdb-4.0.a
> lrwxrwxrwx 1 root root 12 2003-01-15 18:29 /usr/lib/libdb.so -> libdb-4.0.so
> $ ll /usr/lib/libdb-4.0.{a,so}
> -rw-r--r-- 1 root root 860404 2002-04-23 03:29 /usr/lib/libdb-4.0.a
> -rw-r--r-- 1 root root 608708 2002-04-23 03:29 /usr/lib/libdb-4.0.so
>
> $ strings /usr/lib/libdb-4.0.a|grep "Sleepycat.*Berkeley"
> Sleepycat Software: Berkeley DB 4.0.14: (April 23, 2002)
> $ strings /usr/lib/libdb-4.0.so|grep "Sleepycat.*Berkeley"
> Sleepycat Software: Berkeley DB 4.0.14: (April 23, 2002)
>
> configure churns for quite a while, but finally fails like this:
>
> [...]
> checking for Berkeley DB in /usr (as db4)... no
> checking for Berkeley DB in /usr (as db)... no
> configure: error: Could not find Berkeley DB 4.0.14 with names: db4 db
>
> I won't bore you with the details, but after much poking and rummaging,
> I figured out what happened: when conftest.c #include'd <db.h>, it got
> /usr/local/include/db.h, which is from a DB 3.3.11 that I built ages
> ago. No db_version macro there -- in DB 3, it's a function. But
> conftest.c was linked against /usr/lib/libdb.so, ie. DB 4, where
> db_version is a macro, and undefined as a function. Classic DB version
> mismatch, and it would have been detected except for the way db_version
> has changed roles. Arrghghhghh!!! What a pain in the ass.
>
> (Hmmm: even if it was detected by conftest.c, it looks like the real
> error -- DB version mismatch -- would be swallowed by configure.)
>
> So I guess the problem is twofold: 1) gcc apparently puts
> /usr/local/include ahead of /usr/include, but /usr/lib ahead of
> /usr/local/lib, 2) db_version changed from a function to a macro with DB
> 4. Obviously neither one is Subversion's fault, but they sure were a
> pain to me. If nothing else, hopefully this message will sit in the
> archive and be useful to some other poor sod.
>
> Anyways, removing the /usr/local copy of Berkeley DB let configure run
> to completion... and, oh happy surprise, Subversion finally compiled.
> Hooray!
>
> While I'm feeling bitter and vengeful about the whole episode, anyone
> want to help me come up with a marketing slogan for Sleepycat?
>
> "Berkeley DB: keep the riff-raff away"
>
> "Berkeley DB: when you really, really, don't want your software to
> build for *anyone* else"
>
> "Too many damned users taking up your time?
> Try Berkeley DB -- guaranteed to drive them away in droves!"
>
> Err, Subversion folks should not take the above *too* seriously...
> I think...
>
> Greg
> --
> Greg Ward - software developer gward@mems-exchange.org
> MEMS Exchange http://www.mems-exchange.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 16 21:32:03 2003