[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] [nmh-1.2] a serious bug in the nmh configure script

From: Joel Reicher
Subject: Re: [Nmh-workers] [nmh-1.2] a serious bug in the nmh configure script
Date: Fri, 23 Dec 2005 00:47:43 +1100

> Now fixed in CVS. (nmh-workers seems to be eating my emails or being
> very slow with them, so I've also CCd you directly).

I think the mailing list is configured not to resend messages to the

> >Regarding finding ndbm.h, I don't fully understand why the logic in
> >the file is the way it is. The DB_DBM_HSEARCH doesn't actually appear
> >to be used anywhere, so I can't comment on why it looks for db.h "before"
> >looking for ndbm.h.
> DB_DBM_HSEARCH has to be set to get libdb's db.h to provide the
> 'historical' APIs we use. As for ordering, your guess is as good as
> mine, really -- I don't have access to a huge range of systems for
> testing so I mostly left the logic as it was. Really we should be
> checking for lib and header as a single check, but that would be a
> horrendous pile of autoconf.

I understand the issues a bit better now, thanks to


The tests are finding an implementation of the ndbm API. First try
is Berkeley DB version 1, then gdbm, then Berkeley DB version 2. The
problem with the last test is that it is done by only checking for
the existence of db.h, and on NetBSD this header exists for another
reason. I'm not experienced with this kind of thing, but I suspect the
correct fix is to add a usability check for db.h, i.e. see that a call
to some ndbm function can be compiled.

I also think that any lib checks are a separate issue.


        - Joel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]