[Xorp-hackers] chrpath: in-place editing of RPATH in ELF binaries
Bruce Simpson
bms at incunabulum.net
Tue Dec 1 13:12:16 PST 2009
Hi,
So we still have a problem with RPATH. Binaries built in the XORP
$BUILDDIR, currently need to be installed before they may be run. This
is a dog, because it makes it more difficult to run regression tests.
For cross compilation (as yet untested), none of this is an issue, as we
have to stage binaries there anyway; and can't assume that we can run
them on the host.
Over the last week, I fixed this, by forcing the RPATH for simple test
binaries (built with the AutoTest() custom SCons builder) to point into
the right $BUILDDIR/ sub-directory, with some Python magic.
The ideal solution to this problem is for the host system to support the
ELF runtime linker's $ORIGIN feature, which allows library paths to be
specified relative to the executable. Other large C++ projects such as
Firefox, KDE already try to make use of this.
Bruce Simpson wrote:
> Dealing with RPATH is a dog. $ORIGIN support didn't get merged to
> FreeBSD 7, that would be the real answer.
>
It's in FreeBSD 8, but I'm still waiting to hear from kib@ if a backport
is feasible or not.
In the meantime, there's a chrpath utility, which is in the Ubuntu and
Fedora packaging systems. Something which the KDE guys were playing
with, apparently:
https://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath
http://lists.kde.org/?l=kde-buildsystem&m=119809096316066&w=2
I have just rolled a quick FreeBSD port for it, but I haven't committed
it yet (trying to find a willing ports victim^Wcommitter):-
http://people.freebsd.org/~bms/dump/chrpath.shar
I don't really like the idea of dirtying up the link phase, just to deal
with the fact that we want to run from one place, then another. In this
respect, our issues are quite similar to that of KDE's; we have lots of
shared C++ libraries.
chrpath can at least be integrated into the SCons install step, to e.g.
strip out additional RPATH fields if we're on a target where $ORIGIN
isn't supported by the runtime ELF linker. In this situation we have to
build the ELF .so's and binaries with an RPATH pointing to the $BUILDDIR.
As the KDE guys point out, this is very quick, but it does mean a
dependency on an external build tool, where $ORIGIN isn't supported on
the target system.
The alternative is to basically do what libtool does, and forcibly
relink as we're about to install a binary or library.
However, this means modifying the SharedLibrary and Program builders in
SCons, or overriding them, to deal with the disparity; that's quite a
big change.
cheers,
BMS
More information about the Xorp-hackers
mailing list