Re: LD_LIBRARY_PATH exported but libdb-4.6.so not found

You should embed the correct path by adding -R/usr/local/BerkeleyDB.4.6/lib to your LDFLAGS at compile time, or set LD_RUN_PATH before compiling, which works similarly.

It is unwise to leave location of BDB libraries to chance, as if you are relying on OS provided default libraries, they will frequently be wrong or will cause issues, or your newer libraries may not be found.

Linux usually only puts /usr/local/lib and other system paths such as /usr/lib etc., in the default library path.

This is not a workaround, it is just the way it works. You must make sure you provide the same libraries you compiled with, otherwise openldap may fail as it will not find libraries, or default to some system libraries which can be broken or old.

The -R option stores the library location in the executables, at runtime it will look first in this location, before it falls back to using LD_LIBRARY_PATH etc.,

Cheers Brett

On Tue, Oct 25, 2011 at 2:04 AM, Pablo Chamorro C. < pchamorro@ingeominas.gov.co> wrote:

I updated from 2.4.21 to 2.4.23 in some old Fedoras and also in a CentOS 5.4.

Before compiling, I run:

export LD_LIBRARY_PATH=/usr/local/**BerkeleyDB.4.6/lib export CPPFLAGS="-I/usr/local//**BerkeleyDB.4.6/include" export LDFLAGS="-L/usr/local/**BerkeleyDB.4.6/lib"

and it compiles ok. But after installed, in 3 out 4 of the used servers, slapd doesn't start unless I execute first:

export LD_LIBRARY_PATH=/usr/local/**BerkeleyDB.4.6/lib

Attached, the output of ldd /usr/local/libexec/slapd, before and after running export LD_LIBRARY_PATH=/usr/local/**BerkeleyDB.4.6/lib. In short:

without LD_LIBRARY_PATH defined:

   libdb-4.6.so => not found

with LD_LIBRARY_PATH as above:

   libdb-4.6.so => /usr/local/BerkeleyDB.4.6/lib/**libdb-4.6.so<http://libdb-4.6.so>(0x00002b4eb2c16000)

Could you please explain me why this might be happening? Is this a bug? This issue ocurred to me in at least 3 server, but I have another CentOS 5.4, where the compilation and the install process run just fine, and I didn't need that workaround.

Thank you,

Pablo Chamorro