| 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. |