rpath handling

Colin Walters walters at verbum.org
Wed Jun 23 23:58:18 UTC 2010


Hello internet,

So I lost yesterday and part of today to what I thought was a libtool
bug, but turned out to be an interaction with Fedora's current primary
recommendation for rpath handling:

http://fedoraproject.org/wiki/RPath_Packaging_Draft

The main recommendation is to use sed to reach into libtool's guts,
which normally works (well, until libtool changes, then we have a lot
of copy and paste to fix, but that's another story).  However, glib2
uses a program called "gtk-doc" which requires actually running an
uninstalled binary to extract some data from it.  This fails with the
Fedora rpath handling approach because the rpath is required at build
time.

Thus, I came up with this fragment of shell, which has a few advantages:

# make install here
(cd $RPM_BUILD_ROOT; find | while read f; do if file $f | grep -q ':
ELF .*executable,'; then chrpath --delete $f; fi; done)

0) It fixes the above problem I had
1) It doesn't precariously depend on libtool's internal variables
2) It handles rpaths generated by build systems other than libtool

However, after writing this, it occurs to me that RPM itself ships a
check-rpath tool; can we consider defaulting to replacing all rpaths
for standard paths?  From the draft, I don't see any downsides to this
- we wouldn't be stripping rpaths for internal libraries, just stuff
in /etc/ld.so.conf*.


More information about the devel mailing list