Philip Martin <philip.martin_at_wandisco.com> writes:
> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>
>> I seem to recall that it used to be extremely important for Subversion
>> to use the same BDB to which APR was linked. mod_dav_svn used APR's
>> DB support for its activities database, and couldn't deal with having
>> APR's DB being one flavor of BDB while the Subversion repositories
>> which it also needed to read/write needed a different flavor of BDB.
>> Has any of this changed since our move (back in 1.5) away from
>> DB-based activities databases? I mean, could we move BDB detection
>> into Subversion proper and that not be catastrophic?
>
> I suppose it depends on the details of the shared library loading and
> that varies from platform to platform. I don't really know all the
> details or how portable it is.
>
> Apache won't be linked to libdb at all, both mod_dav_svn and apr_dbm_db
> will be loaded by apache at run time. mod_dav_svn may not be linked to
> libdb either as it may also load libsvn_fs_base at run time. So on my
> Linux machine when apache loads apr_dbm_db it gets an ELF NEEDED for
> libdb-X.Y.so and will load that version of the library, when it loads
> mod_dav_svn/libsvn_fs_base it gets NEEDED for libdb-P.Q.so and will load
> that version if not already loaded.
>
> Loading isn't the whole story, we also have to consider symbol
> resolution. APR passes RTLD_GLOBAL to dlopen() so symbols from one load
> are available to later loads. The default for Berkeley DB is that
> symbol names are unchanged from version to version, so symbols from the
> first load would satisfy the second load. However on my Debian system
> the symbols are also ELF versioned (I don't know whether this a Debian
> enhancement) so even when the names are the same they won't match unless
> the version is new enough.
I'm assuming that we still need to coexist with the use of APR's BDB
interface. Even if mod_dav_svn no longer uses it directly I expect
there are auth modules that do, as well as all sorts of unrelated
modules.
--
Philip
Received on 2011-06-21 17:14:39 CEST