This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RPATH/RUNPATH issue, equivalent to -headerpad on OSX
- From: Alexander Neundorf <neundorf at kde dot org>
- To: binutils at sourceware dot org
- Cc: Mike Frysinger <vapier at gentoo dot org>
- Date: Thu, 3 Jan 2008 16:41:32 +0100
- Subject: Re: RPATH/RUNPATH issue, equivalent to -headerpad on OSX
- References: <200801031354.05013.neundorf@kde.org> <200801031018.33979.vapier@gentoo.org>
- Reply-to: neundorf at kde dot org
On Thursday 03 January 2008, you wrote:
> On Thursday 03 January 2008, Alexander Neundorf wrote:
...
> > 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.
I must admit that I didn't try to use it for cross compiling. OTOH when cross
compiling, why would you need different RPATHs ? You won't be able to run it
in the build tree anyway.
How is the RPATH endianness related ?
Can you please elaborate on the multi lib stuff ?
> 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.
I didn't know about scanelf, will check.
> > 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.
It's optional and not yet released, so if there are problems it's still time
to work on that.
...
> > 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 ...
I don't think so. How would a better solution look like ?
Alex