Re: RPATH/RUNPATH issue, equivalent to -headerpad on OSX

[Alexander Neundorf <neundorf at kde dot org>]

On Thursday 03 January 2008, you wrote:
> On Thursday 03 January 2008, Alexander Neundorf wrote:
> > 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 ?
>
> i'm not talking about the RPATH string, i'm talking about the ELF.  the
> RPATH is a straight up string, so there is obviously no bit/endian issues
> with the string data.  but how does chrpath know where to find the RPATH
> string data ? by parsing the ELF headers which can be 32bits or 64bits and
> little or big endian.  read the chrpath code and it's obvious it will not
> scale without a complete overhaul.

I'll have a look. 
Anyway this is currently for me still better than nothing, the usage of 
chrpath could be limited to ELF/x86/32bit, which would already work for a 
very big percentage of developers on ELF platforms.
Disabling it completely for cross compiling also doesn't sound like a 
significant problem.

Can you please explain the multi lib stuff ?
Basically I know only that e.g. for ARM you have several versions (thumb, 
float, etc.) of the same lib and somehow you have to get the right one. I'd 
be happy to gain even deeper knowledge on that ;-)

> > > 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.
>
> feel free to e-mail any questions/issues to {vapier,solar}@gentoo.org

Is there a source package available somewhere (I'm not on Gentoo) ?
What is the command for changing the RPATH from bar to foo ? The documentation 
is a bit terse.

> > > > 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 ?
>
> a way for objcopy to modify random DT tags in ELFs would be perfect i would
> think.  objcopy --change-dt <idx> <value>.  then you'd figure out the index
> of the RPATH tag (let's say it's the 5th tag) and do something like:
> for elf in ${list-of-kde-elfs-to-screw-with} ; do
> objcopy --change-dt 5 "/some/random/craziness:/insane" $elf
> done

This would take somewhat longer than just changing something inside an 
existing file, but I would happily use it :-) (would be more official and 
less hackish)

Actually objcopy and friends were the place where I looked first for a way to 
modify RPATH. But they currently can't do that, so the only thing I found was 
chrpath.

Alex