Philip Martin <philip.mar...@wandisco.com> writes: > "C. Michael Pilato" <cmpil...@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
