On Apr 4, 2013 12:17 AM, Russ Allbery r...@stanford.edu wrote:
Daniel Pocock dan...@pocock.com.au writes:
I use a Debian system to run autoreconf and bootstrap/make dist releases
for various projects (e.g. reSIProcate)
When using the release tarball on a system like Fedora, issues with
hard-coded rpath have been discovered.
Apparently I am not alone, and this discussion has come up before in RPM
packaging. On the RPM packaging request for reSIProcate, I've gathered
links to a few different discussions about the issue:
https://bugzilla.redhat.com/show_bug.cgi?id=892625#c11
This appears to actually be a Libtool issue, not Automake. Cc'ing the
relevant mailing list.
The key message appears to be:
http://lists.fedoraproject.org/pipermail/packaging/2010-June/007187.html
which says that Fedora patches Libtool to recognize /usr/lib64 as a system
library path so that Libtool won't generate rpath references to it.
If that's still the case, it seems like that's something that Libtool
should add in the upstream source. It seems unlikely to me that a system
would have a /usr/lib64 directory that isn't part of the standard search
path; either that path pattern won't be used at all (as with Debian/Ubuntu
multiarch) or it will be the 64-bit multiarch system library path.
I actually made a patch for glibc's ldconfig specifically so that the
system library paths could be reliably detected by libtool and rpath would
not be set on those directories. Unfortunately it stalled in review and I
haven't gotten back to it for a while. This has been a long standing
problem using libtool. I'll see if I can get that going again. It's
somewhere on libc-alpha if anyone wants to take a look, but I'm on my phone
right now.
Dan
