that's slightly different Karl.
what was needed was a method to specify which Directory to look
for db3 in.

as far as having building on a different machine, that's frought with
errors anyway.
for example.. we just patched a solaris machine.. innocent enough, but
all of a sudden it was looking for sendfile.
maybe a --disable-berkeley-db and a --disable-gdbm as well as a
--with-berkeley-db-inc/lib and --with-gdbm is required?

> -----Original Message-----
> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> Sent: Monday, December 10, 2001 12:03 PM
> To: Justin Erenkrantz
> Cc: Doug MacEachern; dev@apr.apache.org
> Subject: Re: disabling dbm stuff
>
>
> Justin Erenkrantz <jerenkrantz@ebuilt.com> writes:
> > On Mon, Dec 10, 2001 at 11:12:31AM -0800, Doug MacEachern wrote:
> > > there needs to be a way to turn off db, gdbm, etc.  for example:
> > >
> > > --enable-dbm-only=sdbm (turn off everything except sdbm)
> > >
> > > --disable-dbm=gdbm (turn off just gdbm)
> > >
> > > doesn't matter what the configure arguments are called, but this
> > > functionality needs to be in place.
> >
> > What's the motivation for this?  -- justin
>
> I know with the Subversion project (which requires specific versions
> of Berkeley DB) ran into some configuration conflicts with APR's
> recent db changes.  The build would look like it had gone fine, but
> then at run-time, the Subversion server would attempt to dynamically
> load Berkeley 3.3.11, and get 3.1.17 instead (the latter being what
> APR/Apache built with, iirc).  This only started happening with the
> recent dbm tweaks in APR.
>
> Unfortunately, I can't remember the issue in detail, but could
> probably dig it up out of the Subversion mail archives if necessary.
> Mike Pilato <cmpilato@collab.net> dealt with this problem in detail at
> the time.
>
> Anyway, this is one example where controlling the dbm at build time
> would have been helpful.
>
> -Karl
>