Re: BDB mismatch problem

[Buchan Milne <bgmilne@obsidian.co.za>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Villy Kruse wrote:
> On Tue, 2 Aug 2005, Buchan Milne wrote:
> 
> 
> 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.

Yes, most distributions handle this ... and usually any package that may
require the utils will require the correct version.

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

But, should it be necessary. Clean software doesn't need this kind of
hack under typical circumstances.

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

In most cases (assuming we are still talking about currently available
linux distributions that seperate run-time libraries from development
libraries), you *can* only have one installed at a 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.

But, because the runtime library is the library with the soname, if
OpenLDAP's configure script can't choose better, it's going to find the
wrong library in many cases.

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

Exactly, now you're seeing the problem.

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

It wouldn't (get interesting), the package wouldn't complete 'make test' ...

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

Which is trivial to do (and, actually unnecessary for OL2.3, since slapd
will run recovery at startup now when necessary). Avoiding having the
run-time library for db-4.3 installed on a shared (by many contributors,
building all kinds of software) build host may not be possible for much
longer.

Regards,
Buchan

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

iD8DBQFC73JArJK6UGDSBKcRAm6mAJ9uxZHOUI/Vh53HGxI10D5MgXIu4gCfaxhb
J5Q1gP5snnyou+Zxg2FZCJ4=
=jPkT
-----END PGP SIGNATURE-----