[Date Prev][Date Next]
Re: BDB mismatch problem
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
> configure from OpenLDAP will try to link using librarie names which belong
> in the runtime libraries, because they represent the soname of these
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' ...
> 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
> 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
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
-----END PGP SIGNATURE-----