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
