Re: BDB mismatch problem

[Villy Kruse <vek@pharmapartners.nl>]

On Tue, 2 Aug 2005, Buchan Milne wrote:

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

No versions of Brekely DB has the soname "db".  That defeats the purpose
of having a soname.

The whole point is to avoid linking against the soname at link time,
because you can then make sure the Openldap configure don't have too many
bad choices.  The soname is required at runtime and cannot therefore
be deleted.  Any other name such as libdb or libdb-4 is use at link
time only and the soname inside the library will then determine which
name will be used at run time.

With other libraries you normaly specify a generic library name at compile
time such as -lcrypt or -lm.  The soname for libcrypt for example could
be libcrypt.so.1 and that name is use at runtime.  I don't think you
could even specify the soname for libcrypt using the -l flag.

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

Default installation using BerkeleyDB dist/configure without any parameters
crates these files.

-rw-r--r--    /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.a
-rw-rw-r--    /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.la
-rwxrwxr-x    /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.so
lrwxrwxrwx    /usr/local/BerkeleyDB.4.3/lib/libdb-4.so -> libdb-4.3.so
-rw-r--r--    /usr/local/BerkeleyDB.4.3/lib/libdb.a
lrwxrwxrwx    /usr/local/BerkeleyDB.4.3/lib/libdb.so -> libdb-4.3.so

Of these only /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.so is needed at
runtime.

Another complication is that different installed versions create different
versions of the db databases and that would require different versions of
db_recover among other things.  That is a different can of worms, though.

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

Perhaps that isn't a problem.  If you have write access to $HOME/lib
and create the symlink there, and arrange for the openldap build to look
for libraries in this directory, that might work.

> >  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
> gtkhtml).
>

It seems BerkelyDB is more than unusualy bad.  Try compare different
versions of db.h and see that #define's get changed for no appearent
reasons.  If db.h didn't change so much between versions it would be
less of a problem.

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

Which could make things easier in a way.  You only need to have one
version of the devel packages installed at any point in time.  However,
configure from OpenLDAP will try to link using librarie names which belong
in the runtime libraries, because they represent the soname of these
libraries.

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

That would be nice: if configure could select the proper library given
a db.h and for example select db4.2 when the header is db4.2 even if
db4.3 is also installed on the system.

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

Hopefully cyrus-sasl isn't compiled using a confliction version of db.h
Things could get mighty interesting if openldap loads one db verions and
cyrus-sasl loads another version into the process address space.  I
never tried it, though.

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

That is so true.  You still need a proper version of db_recover, though.

Villy