Picking up wrong version of db at link time

I've been trying to build subversion 0.19.1 on what's basically a
Slackware 8.0 system. I downloaded db v4.1.25 and built that first,
installed so that it appears under /usr/local/{bin,lib,include} etc.
(Actually it's installed somewhere else with symbolic links (stow-style)
to point from /usr/local to the real place, but I doubt that matters.)
Slackware 8.0 installs db 3.1.17 with libraries in /libi and /usr/lib,
headers in /usr/include (e.g. /usr/include/db.h).

I configured subversion with

CC=gcc CFLAGS=-O2 ./configure --prefix=whatever

and this appeared to find the header for db 4.1.25 in
/usr/local/include. However, when I link I get subversion binaries that
are dynamically linked against both libdb-3.1.so and libdb-4.1.so. If I
temporarily remove /lib/libdb.so, I find I'm getting code statically
linked into (e.g.) svnadmin from /usr/lib/libdb.a. (What happens is
when I try to run 'svnadmin create' I get a complaint that version
3.1.17 is not recent enough. Running nm on the subversion dynamic
libraries, I find they've got functions like db_version with ' T ' next
to them.)

So, I think there's some kind of problem where despite the right version
of db being found during the configure step, that version doesn't get
used as first-choice during linking.

(BTW, I'm currently not in a position to just discard libdb-3.1, because
I have other apps linked against it that I wasn't planning to rebuild.)

As a workaround for now, I've been temporarily moving all the db-3.1
stuff out of the way whilst subversion is building, then reinstating
them afterwards. It would be good to have a less clunky solution to the
problem though.

Richard.

-- 
Richard P. Curnow | Free software fundamentalist
Weston-super-Mare | 
United Kingdom    | http://www.rc0.org.uk/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org