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
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:email@example.com]
> Sent: Monday, December 10, 2001 12:03 PM
> To: Justin Erenkrantz
> Cc: Doug MacEachern; firstname.lastname@example.org
> Subject: Re: disabling dbm stuff
> Justin Erenkrantz <email@example.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 <firstname.lastname@example.org> 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.