This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |