Hi,
On Wed, 14 Apr 2010, Ondřej Surý wrote:
On Tue, Apr 13, 2010 at 10:29, Ville Mattila <[email protected]> wrote:
I am not an expert, but I have some experience from Debian, where we
fight rpath quite usually.
Usually rpath is evil for distributions, since it causes all the
strange things like the one you have described, etc., etc.
Indeed, Debian seems to discourage rpath usage in packages:
http://wiki.debian.org/RpathIssue
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)
Thanks for the hint. I'll try if mangling the binaries chrpath would
let me ditch some of the awful sed etc. hacks I've currently in the RPM
package for building a custom new enough sqlite and statically linking
it into the opendnssec binaries.
(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.
Yes it is a problem.
If I expose the custom sqlite3 libraries by adding their install path
(/opt/opendnssec-sqlite/lib) to ld.so.conf it would be practically same as
replacing the system default sqlite3 installation directly (in /usr/lib*):
All programs (including e.g. /bin/rpm) would thereafter be linked to my
custom /opt/opendnssec-sqlite/lib/libsqlite3.so.0 and nobody would be
using the official /usr/lib*/libsqlite3.so.0. I'm afraid of the
newer sqlite3 libraries being incompatible/buggy wrt RHEL5 tools and
thus would prefer only opendnssec using the custom sqlite3 libraries.
But perhaps it is not a problem for most users to (effectively) replace
RHEL 5 official sqlite in their OpenDNSSEC servers.
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.
I'm using the ods-control delivered with opendnssec-1.0.0 as init script
so yes, LD_LIBRARY_PATH could be exported from there and that should be
enough provided ods-enforcerd and the signer engine would never get
started directly but always via the init script.
You can also use aliases in your shell,
like:
alias ods-enforcerd="LD_LIBRARY_PATH=/usr/local/lib /tmp/xxxxx/ods-enforcerd"
Sure. Another trick could be creating a script e.g.
/usr/libexec/opendnssec/bin/ods-wrap:
-----
#!/usr/bin/perl -w
use File::Basename;
$ENV{LD_LIBRARY_PATH} = "/opt/opendnssec-sqlite/lib";
exec("/usr/libexec/opendnssec/bin/" . basename($0), @ARGV);
-----
The real ods-* binaries would thus be installed into
/usr/libexec/opendnssec/bin/ and symlinks with the same names
would be placed instead in /usr/bin/. For example:
/usr/bin/ods-ksmutil => /usr/libexec/opendnssec/bin/ods-wrap
/usr/libexec/opendnssec/bin/ods-wrap => ods-ksmutil
So far all the methods for installing OpenDNSSEC on RHEL5 without
replacing the default sqlite seem rather tedious (at least from package
maintaining perspective). Statically linking a custom sqlite version
can be done and seems to work ok in our test setup. I'll see if the
chrpath mangling and/or shell aliases + init script modification for
exporting $LD_LIBRARY_PATH would result in cleaner (i.e. easier to
maintain and thus better) package.
Ville_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
