alternate-bdb-version [plain text]
This file contains brief notes on building Subversion using a version of
Berkeley DB other than that which APR-util is linked to.
This is not an officially supported configuration, but can occasionally be a
useful thing to do.
Section 1: Building Berkeley DB
-------------------------------
It is necessary that the Berkeley DB installation you build not conflict with
the one that _is_ linked to APR-util, in two ways:
1) In the filesystem.
If you are installing to a separate prefix, this is not a problem.
If, on the other hand, you are preparing a system package for installation
under /usr, you must delete or rename several things after running
'make install', but before your packaging system gathers the files into
the final package:
lib: Delete libdb.a, libdb.so and libdb-4.so, which should leave you with
only files containing the full 4.X version of Berkeley DB in
their names.
bin: Rename each executable replacing the string "db_" with "db4.X_" in
each case.
include: Move all the include files that are installed into a subdirectory
called "db-4.X". Additionally, create a symlink within this
subdirectory called "db4", pointing to ".". This is because APR-util
may well be attempting to include <db4/db.h>. See the file apu_want.h
to know whether this symlink is actually required on your system.
docs: Put the installed Berkeley DB documentation for this version
whereever seems appropriate for your distribution.
2) In symbol names.
A more insidious kind of potential conflict exists where mod_dav_svn is
concerned. Without care, due to the way some dynamic linkers work, when
loaded within Apache HTTPD, libsvn_fs_base may dynamically resolve the
Berkeley DB symbols via the already-loaded APR-util, rather than the
intended version. Fortunately, Berkeley DB comes ready-equipped with a
way to prevent this. You must configure Berkeley DB with the parameter
--with-uniquename=_someuniquestring. Personally, I suggest _db4X. This
will result in the Berkeley DB symbols being suffixed with this string,
avoiding the mentioned problem.
Section 2: Building Subversion
------------------------------
OK, you have a suitable version of Berkeley DB. Now you need to trick
Subversion into linking with it, despite the fact that Subversion's build
system is geared to taking the Berkeley DB linkage options from APR-util.
Ensure that the development packages for the version of Berkeley DB that your
APR-util is linked to _are_ installed, because we want configure to find a
working Berkeley DB, so we can just override its choice of installation with
some Makefile editing later.
Configure Subversion as normal, then edit the Makefile:
Alter the definition of SVN_APRUTIL_LIBS, removing any existing -ldb, -ldb4,
or -ldb-4.X option, and add *at the beginning*, the appropriate -ldb-4.X
option for your desired Berkeley DB version. Add an -L/path/to/libs option if
needed.
Alter the definition of INCLUDES, adding *at the beginning*, the appropriate
-I/usr/include/db-4.X option.
Last issue: Despite this meddling, libtool still fetches a -ldb option for the
version of Berkeley DB linked to APR-util from the APR-util .la file, and uses
it when linking the command line programs. Because of the use of
--with-uniquename above, this is not a problem per se, but it does result, on
Linux, in the addition of spurious DT_NEEDED dependency records to the
binaries, such that they claim to be dependent on BOTH the alternate AND
APR-util versions of Berkeley DB, despite the fact they never invoke code in
the linked-to-APR-util version. This can be avoided by setting
EXTRA_LDFLAGS="-Wl,--as-needed", though you should be aware that this will
likely strip off several other DT_NEEDED records too, none of which should be
necessary, but with the complexities of shared library linking, you should
probably test that this hasn't had any unforeseen side-effects.
Now make. If all goes well, your newly built Subversion should be using your
alternate Berkeley DB version.