[Opendnssec-user] CentOS RPM distribution

[Ville Mattila]

Hi,

On Fri, 9 Apr 2010, rzarouali at gmail.com wrote:

> Agree but it is somehow broken
>
> I'll post here specs I've used this evening so you'll see changes I've made on it.
> I have also created specs for dnsruby, softhsm

Please do send you .specs.  I've noticed some needs for enhancing the
default opendnssec.spec, too, and would like to see what you've come
up with.

Most importantly:  How have you solved the problem of OpenDNSSEC 
requiring SQLite v3.4.2 or newer and RHEL 5 providing only SQLite 3.3.6?

I'd prefer not upgrading the RHEL 5 official sqlite package (as e.g. RPM
itself depends on it).  Already tried repackaging Fedora 12's
sqlite-3.6.20 into /opt/opendnssec-sqlite/ but I suspect that in 
opendnssec-1.0.0 specifying "configure --with-sqlite3=PATH" only works 
if PATH is /usr/local/lib and nothing else.  See below for my findings.

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.

For example on my RHEL 5 box when opendnssec is compiled with
"configure --with-sqlite3=/opt/opendnssec-sqlite --libdir=/usr/lib64"
the binaries will end up using wrong sqlite libraries:

$ ldd /usr/bin/ods-ksmutil | grep sqlite
         libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x0000003588400000)
$ readelf -d /usr/bin/ods-ksmutil | grep RPATH
  0x000000000000000f (RPATH)              Library rpath: [/usr/lib64]

I was wondering is RPATH really necessary and if yes, should it perhaps
point to list of sqlite etc. library locations instead of the configure
--libdir specification?

Or am I totally lost in my conclusions?

Ville

PS. If I run configure without --libdir option (just plain "./configure &&
make) the RPATH will be /usr/local/lib and installing the newer sqlite
libraries there both ods-enforcerd and ods-ksmutil work perfectly.