[Gelistirici] Fwd: Re: RPATH/RUNPATH issue, equivalent to -headerpad on OSX
S.Çağlar Onur
caglar at pardus.org.tr
4 Oca 2008 Cum 00:03:39 EET
Bu bilgiler ışığında chrpath'den kurtulup scanelf'e yönlenmek daha doğru
olacak sanki?
---------- Yönlendirilmiş İleti ----------
Subject: Re: RPATH/RUNPATH issue, equivalent to -headerpad on OSX
Date: 03 Oca 2008 Per
From: Mike Frysinger <vapier at gentoo.org>
To: binutils at sourceware.org, neundorf at kde.org
On Thursday 03 January 2008, Alexander Neundorf wrote:
> I am working on the build system for KDE4 and in KDE we are relying a lot
> on RPATH/RUNPATH.
kind of sad how every solution you talk about here is already taken care of
transparently by libtool ... but at any rate ...
> There is a tool called chrpath available which does that:
> http://linux.die.net/man/1/chrpath
> http://websvn.kde.org/trunk/kdesupport/chrpath/
>
> But this tool has a problem, it only works if the new RPATH is not longer
> than the RPATH which is already in the ELF file (since it basically just
> patches the binary).
actually, that isnt its only problem. imnso, chrpath is a quick hack that
works for $author but does not scale at all beyond that. it only works on
ELFs that match the system you're building on, so you can forget about
cross-compiling or even multilib (when bitsize is different). either you
move chrpath in house to make it not limited, or you screw your users by not
allowing them to cross-compile or build multilib anymore.
that is why in Gentoo, we abandoned chrpath and instead used `scanelf -X`.
scanelf handles the target endianness/bitness properly. scanelf however does
not dynamically adjust the string size accordingly either, it just truncates
RPATH/RUNPATH down to the minimum. perhaps it could be extended, but there
was no such need/demand in Gentoo for it.
> Since a few days CMake (http://www.cmake.org) supports chrpath, i.e.
> instead of linking again when installing chrpath is used to modify the
> RPATH inside the binaries. A workaround for the mentioned problem is
> implemented here: if the RPATH for the install location is longer than the
> RPATH for the build location, then the RPATH for the build location is
> padded with separator characters. This works.
> But of course it would be much nicer if there was an official way to do
> this.
i hope cmake is fully aware of chrpath's limitations and documents it properly
before people start relying on it.
> On OSX there is the -headerpad <size> option for ld, which basically does
> just that. So if you know that the RPATH for the install location is 200
> byte long, then you use -headerpad 200 and the linker will make sure that
> the field for the instll name will be at least 200 byte long.
>
> It would be nice if the ELF ld would offer a similar option,
> e.g. -rpath-length=<size>, and then the RPATH field would have the
> specified size. This would make it possible to safely modify the RPATH
> without workarounds.
> Maybe this would even make sense for binary distribution packages, where
> (maybe) the install location could be selected and then the RPATH inside
> the binaries of the package could be modified.
seems like this is a stopgap measure and not a real long term solution ... but
who knows, maybe such a stopgap hack will work for your issue.
-mike
-------------------------------------------------------
--
S.Çağlar Onur <caglar at pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/
Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: kullanılamıyor
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20080104/158c8d08/attachment-0002.pgp>
Gelistirici mesaj listesiyle ilgili
daha fazla bilgi