[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: BDB mismatch problem

Hash: SHA1

Villy Kruse wrote:
> On Mon, 1 Aug 2005, Jon Roberts wrote:
>>Date: Mon, 01 Aug 2005 18:53:18 -0500
>>From: Jon Roberts <jon@jonanddeb.net>
>>Reply-To: man@mentata.com
>>To: Howard Chu <hyc@symas.com>
>>Cc: Openldap list <openldap-software@OpenLDAP.org>
>>Subject: Re: BDB mismatch problem
>>Howard Chu wrote:
>>>See ITS#3809.
>>Wow. Thanks!
>>It worked fine with the following in my (tcsh) environment:
>>setenv CC gcc
>>setenv CFLAGS "-O -g"
>>setenv CPPFLAGS "-I/usr/local/include"
>>setenv LDFLAGS "-L/usr/local/lib"
>>setenv LD_LIBRARY_PATH "/usr/local/lib"
>>setenv ol_cv_db_db_4_dot_3 no
>>I understand Kurt's reasoning, but if BDB 4.2.52 is still preferred over 4.3
>>for OpenLDAP installs, I personally would side with Walter on redoing the way
>>configure finds this particular library.
> In my oppinion it would be easier to let configure only try -ldb.

Except that the soname for most versions of Berkeley DB are *not* "db",
but "db-4.1" or "db-4.2".

>  One can
> then make sure libdb.so is a symbolic link to whichever library version you
> intend to link with.

This is non-standard ... the Berkeley DB install target does not do
this, and I don't believe and distributions ship the symlink.

BTW, also note that not everyone building software has the luxury of
root access on the build host ...

>  Same for db.h.

Well, it is easier for headers than for libraries.

>  You could even remove libdb.so and
> link againts libdb.a if you don't want slapd to depend on a specific version
> of the db runtime library.  The BerkelyDB is a bit special because it is
> quite sensitive to the proper matching of db.h and libdb.so.

This goes for any library that has been through a few major versions (ie

The point is that a number of distributions provide library packages (ie
 libdb-4.2.so in libdb4.2, and libdb-4.3.so in libdb4.3 package)
seperately from development packages (which would normally contain the
symlink to the appropriate version of the library - but no in the case
of Berkeley DB - and the headers).

There are obvoius uses to having the library available, but not headers,
but no real use for the headers without the library.

Thus, IMHO, the headers are authoratative, not the library.

I'll use the workaround (setting ol_cv_db_db_4_dot_3) for the Mandriva
packages, but fixing the bug would be better.

It's time to realise that the presence of a library does not imply the
presence of the headers, the static development library, the samples,
the documentation etc etc etc that may have shipped in the original
tarball ...


- --
Buchan Milne                              Systems Architect
Obsidian Systems                  http://www.obsidian.co.za
B.Eng          RHCE (803004789010797),LPIC-1 (LPI000074592)
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org