[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian: apu-config and BDB

[Ben Reser]
> It's an abuse of apu-config that's true.
> My understanding (as well as other SVN devs understanding) was that
> we did this because we were concerned about potentially getting a
> different version of BDB by way of APR-UTIL than what we were linked
> against when we're run inside httpd.  Our error messages seem to
> imply this...

Specifically, on certain platforms, getting multiple versions of BDB
linked into your executable at runtime is problematic.  (Same is true
of many other libraries, btw.  Debian has historically had a lot of
trouble with this issue in libpng, for example.)  So, e.g.,

    Apache -> apr-util -> db-4.6
           -> mod_dav_svn -> libsvn_fs -> libsvn_fs_base -> db-4.7

then on some platforms this can either cause apr-util to accidentally
use 4.7 instead of 4.6, or libsvn_fs_base to use 4.6 instead of 4.7.
This can cause corruption and crashing as they are not ABI-compatible.

The concern with Apache and mod_dav_svn pulling in distinct versions of
bdb at runtime is at least one of the reasons Subversion historically
used apu-config to detect the db version.  (Another reason may have
been "laziness", as properly detecting a db dev environment could
historically be a bit complicated.)

However: if you build it right[*], none of the above is a problem on
Debian.  Debian's db-4.4, db-4.6, etc., can indeed coexist in a single
process at runtime without problems, thanks to the magic of symbol
versioning, which I believe may be handled by Debian-specific patches
to BDB.

    [*] _If_ you build it right.  We actually had the opposite problem
    in Debian at some point: Subversion at the time did _not_ actually
    link BDB explicitly, only implicitly via apr-util.  And thus, when
    apr-util was rebuilt to use a newer version of BDB, and
    libsvn_fs_base was not, libsvn_fs_base ended up using the wrong BDB
    ABI and hilarity ensued.  This was fixed by making sure Subversion
    did indeed explicitly link BDB - thus _causing_ mod_dav_svn and
    apr-util to use a distinct BDB, so recompiling one to use a newer
    BDB did not affect the other.

Therefore, I haven't checked how Ben has patched around the issue in
Subversion, but I would guess that the following can be relied upon:
OSes in which apu-config does not spit out irrelevant libraries (i.e.,
Debian and derivatives) are also OSes in which it is safe to link
multiple BDB versions into the same executable (i.e., the Apache +
mod_dav_svn situation).

...Sorry this went a bit long,
Peter (with ties to Subversion, Debian, and Debian Apache maintenance)

Reply to: