[Opendnssec-user] Problem with custom sqlite install path (was Re: CentOS RPM distribution)

[Ondřej Surý]

On Tue, Apr 13, 2010 at 10:29, Ville Mattila <vmattila at csc.fi> wrote:
> Hi,
>
> On Mon, 12 Apr 2010, Ville Mattila wrote:
>
>> If I specify "configure --libdir=SOME_PATH" the ods-* binaries will be
>> linked with RPATH set to SOME_PATH.  This causes problems on RHEL 5 where
>> rpmbuild needs to use "--libdir=/usr/lib64"; and that's where the official
>> (and incompatible to opendnssec) sqlite runtime libraries sit.
>
> Any dynamic linking experts around here?

I am not an expert, but I have some experience from Debian, where we
fight rpath quite usually.

> Thinking further, if I've understood correctly the purpose of RPATH
> in dynamic linking then certainly is nothing wrong with libtool adding
> $libdir in RPATH.  On the contrary, $libdir probably has to be listed in
> RPATH for the linker to be able to find required opendnssec libraries
> should $libdir not be listed in e.g. /etc/ld.so.conf or $LD_LIBRARY_PATH.

Usually rpath is evil for distributions, since it causes all the
strange things like the one you have described, etc., etc.

> My question to OpenDNSSEC developers is that do you think "libtool
> --mode=link" calls should include also "-rpath $SQLITE3" argument
> where $SQLITE3 is the path specified by the user with "configure
> --with-sqlite3"?  Without this I'm unable to see how runtime linker
> ever could locate the correct SQLite libraries that might reside
> elsewhere from $libdir.

Usually it's much better to not have rpath in binaries and let the
dynamic linker do it's work.

But that's not your case - Try to find utility named chrpath and run
chrpath -r ${SQLITE3_PATH} ${binary} .
(http://linux.die.net/man/1/chrpath)

>  (And obviously adding $SQLITE3 to ld.so.conf
> is not an acceptable option because all other programs runtime linked
> to SQLite would end up using the custom libraries as well.)

And is that a problem? sqlite3 libraries have same SONAME, so they
should be compatible with newer sqlite3 library.

> BTW, a workaround for this could be hide the actual opendnssec binaries
> under e.g. /usr/libexec/opendnssec/ and create (a) generic wrapper
> shell script(s) into /usr/bin/ and /usr/sbin/ that export(s)
> LD_LIBRARY_PATH=$SQLITE3 before exec'ing the actual binary.

Do you have some start scripts for opendnssec? It should be enough to
add LD_LIBRARY_PATH to them. You can also use aliases in your shell,
like:

alias ods-enforcerd="LD_LIBRARY_PATH=/usr/local/lib /tmp/xxxxx/ods-enforcerd"

Ondrej
-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/