On 2006-06-21, Bas Wijnen <[EMAIL PROTECTED]> wrote:
> I think it is a Debian-specific issue, due to the upstream libtool maintainer
> having a disagreement with Debian about rpath. He considers it a feature
> which should always be used, we consider it a feature which may be useful in
> some special cases (in particular, hand-build libraries installed in
> non-standard locations, such as under a user's home directory), but mustn't be
> used for normal distribution-installed libraries (which work fine without it).
This is not longer the case. I don't think it's been the case for over 6
years actually! This looks like the relevant entry from libtool's (upstream)
ChangeLog.1:
2000-01-12 Thomas Tanner <[EMAIL PROTECTED]>
[...]
* ltconfig.in: set hardcode_into_libs = yes for GNU/Hurd, Linux
and Solaris, only hardcode *all* run-paths if hardcode_into_libs
is set to 'all', otherwise hardcode only user-specified rpaths
into libraries
And that was released with libtool 1.4 on 2001-04-25 it appears.
The behaviour with libtool 1.5.22 (built from source without any debian
specific patches) is that you don't get an RPATH for --prefix=/usr, but do if
you build with something like --prefix=/home/olly/install - I've just checked
this by building a package with two different prefixes and checking if it has
RPATH set using:
readelf -a <PROGRAM>|grep RPATH
I suspect the issue here is that libtool's "is this a system directory"
test is being confused somehow. I don't have a debian x86_64 system, but I've
just tried a package with vanilla libtool 1.5.22 on an Ubuntu dapper x86_64
system with --prefix=/usr --libdir=/usr/lib64 and I *don't* get /usr/lib64
added to rpath. Running the ubuntu 1.5.22 package's libtoolize --force and
rebuilding from clean doesn't change that for me.
Cheers,
Olly
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
