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

[Mike Frysinger <vapier at gentoo dot org>]

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.

> > 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

> > > 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
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.