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

   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>