Problems building on Debian unstable

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