[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