for bdb, i always thought this is easy:
- /usr/local/db4.0
- /usr/local/db4.1
and you are done.
how is it possible to use two different versions of svn in the same
httpd, like a svn_mod_dav.so, and a svn_mod_dav_dev.so? or svn1.0,
and svn1.1?
-s
---------------------------------------------------------------------
Subject: Re: Problems building on Debian unstable
From: Ben Collins-Sussman <sussman@collab.net>
Date: 16 Jan 2003 14:45:14 -0600
Content-Type: text/plain; charset=us-ascii
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.
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 17 09:46:48 2003