[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compiling problem on OBSD2.7 (ndbm).
On Wed, Nov 15, 2000 at 01:32:16PM +0300, Andrew P. Kokarev wrote:
> On Tue, Nov 14, 2000 at 11:27:28PM -0000, Tomasz Bojakowski wrote:
> > Someone posted, that he needs sockaddr path to compile zmailer on
> > OpenBSD 2.7 (afair I've made same thing for sockaddr a few months ago)...
Bojakowski is right, it got buried and thus lost when I didn't handle
it immediately back then. I am afraid a few other similar things may
have happened.
> > But what about this ? I still have it... and realy don't know if it is
> > problem of zmailer or my includes.
Your system has a serious problem. And OpenBSD package makers have
an even larger one, I am afraid..
> > ndbm.c: In function `owner_ndbm':
> > ndbm.c:274: `DBM_PAGFNO_NOT_AVAILABLE' undeclared
> > (first use in this function)
> > ndbm.c:274: (Each undeclared identifier is reported only once
> > ndbm.c:274: for each function it appears in.)
> > ndbm.c: In function `modp_ndbm':
> > ndbm.c:297: `DBM_PAGFNO_NOT_AVAILABLE' undeclared (first use in this function)
> > *** Error code 1
> >
>
> Yes, configure does not detect that NDBM in FreeBSD & OpenBSD is
> emulated by Berkeley DB 1.85.
> As I have no real .dbm bases to use, nor real NDBM library,
> I just commented out the following line in config.h
> #define HAVE_NDBM_H 1
> Then Zmailer uses native DB 1.85 dbopen() from libc without problems.
Unfortunately the AutoConfig scripts work in such a manner which make
it impossible to revoke detection of some headers. That is, as much
as I would like "undiscover" existence of ndbm.h when it is produced
as a side-result from BSD DB 1.85, I can't.
> On the other hand, if you've installed Berkeley DB 2.x or 3.x from SleepyCat
> it never finds them in default locations (bug in configure.in IMHO)
> /usr/local/BerkeleyDB/{include,lib} for 2.x
> /usr/local/BerkeleyDB.3/{include,lib} for 3.0.x
> /usr/local/BerkeleyDB.3.1/{include,lib} for 3.1.x
> (And library is always called libdb.a, no matter which version).
> I don't believe you should use funny -I and -L for default locations.
All libraries are libdb.a and all includes are db.h ??
Yeach!
glibc people integrated these by pushing them into <db1/*>, <db2/*> and
<db3/*> headers, and (/usr)/lib/libdb[123].{a,so} libraries.
At glibc we can have all three+ versions in a peacefull co-existence.
(Similarly scoped <db3.0/*> vs. <db3/*> vs. <db3.1/*> issue may
lurk somewhere, but that is not the topic here.
(glibc people had that SleepyCat scheme initially in use, but they
got a clue amazingly fast..)
I really would like to support e.g. /usr/local/BerkeleyDB*/{include,lib}/
scheme, but it is rather terrible...
... and considering more of it -- instead of profilerating complicated
DB library functions all over, I really should write somewhat generalized
wrapper to call all possible backend databases + plus whatever plugins
people may want to add..
Binding that generalized layer into router might not be easy, but it
should work in other cases.
> I'm not familiar enough with autoconf tools to make correct changes in
> configure.in .
>
> Maybe it's still better to be able to tweak configured db libraries
> and locations from SiteConfig?
No. Those are runtime configuration things, not compile time stuff.
> > Stop in /usr/local/src/zmailer/router/libdb.
> > *** Error code 1
> >
> > Definition of DBM_PAGFNO_NOT_AVAILABLE in my include/ndbm.h :
> > #define dbm_pagfno(a) DBM_PAGFNO_NOT_AVAILABLE
> > Well... I think it should be:
> > #define DBM_PAGFNO_NOT_AVAILABLE dbm_pagfno(a)
> >
> > But I might be wrong (it seems to be a problem of openbsd anyway.)
>
> You are wrong. That definition is correct (there are no .pag file
> when NDBM is emulated by Berkeley DB). But in some cases it may be
> sufficient to
> #define dbm_pagfno(a) dbm_dirfno(a)
--
/Matti Aarnio <mea@nic.funet.fi>