apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Fogel <kfo...@newton.ch.collab.net>
Subject Re: disabling dbm stuff
Date Mon, 10 Dec 2001 20:45:32 GMT
Ian Holsman <Ian.Holsman@cnet.com> writes:
> that's slightly different Karl.
> what was needed was a method to specify which Directory to look
> for db3 in.

Is it different?  Had the proposed flags been available, they would
have solved our problem quickly.  Granted, maybe we'd still have some
followup work to do to find the "right" solution, but in this case, we
needed a fast fix first to get our server back up (we ended up
backdating APR!).

These two points from Doug MacEachern's mail in support of the flags
seem like they apply to our situation:

> - the configure stuff will never be smart enough, something will break,
> there is no way to disable it.  this is already eating up developer time,
> imagine what it will do to users.
> 
> - might have another module loaded in httpd or apr based program already
> linked against a different version of db, gdbm, etc.  BOOM.  similar to
> the expat nightmare we had with 1.3.  or the php vs. perl fiasco with
> different mysql libraries.

?,
-Karl



> 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
> > 

Mime
View raw message