Greg Ward <gward@mems-exchange.org> writes:
> 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?
Because apr has its own DBM API, and it uses whatever version of
Berkeley it can find on your system. What you're running into here is
some kind of header/library mismatch.
> 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.
Just a temporary situation this one time. We normally try to base svn
releases on public httpd/apr/apr-util releases.
> 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.
I feel your pain. This pain has been hounding me for years. It seems
that different versions of BDB simply *cannot* coexist on one box, and
as a result, every OS has implemented its own custom solution to the
problem (renaming libraries, installing them in weird places, etc.)
It makes our ./configure system hellish.
---------------------------------------------------------------------
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:48:39 2003