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

["Gavin Beatty" <gavinbeatty at gmail dot com>]

On Fri, Aug 8, 2008 at 2:21 AM, Alan Modra <amodra@bigpond.net.au> wrote:
> On Thu, Aug 07, 2008 at 11:47:55PM +0100, Gavin Beatty wrote:
>> I'm trying to ready a patch for submission about this issue. I would
>> add an -rpath-pad option taking the number of bytes to pad the
>> RPATH/RUNPATH.
>
> Make things easy for yourself and do without this option entirely.  If
> you are padding rpath, presumably it is so you can later change rpath.
> So instead of a new option to pad with nulls, pass a dummy large
> string to --rpath, then use your new tool to change rpath.

At the moment we're doing this (KDE/CMake). We pad the string with
':'s because it's currently impossible to pad with '\0's. The point of
being able to pad with NULLs is that we want to pass a valid rpath
value (build tree) AND leave space for changing to a different, longer
rpath value later (at install). The tool is chrpath BTW.

> You should be aware that mucking with .dynstr is dangerous.  Strings
> are merged, so a symbol or tag that just happens to match the tail of
> your rpath value will point at the tail..

Apart from knowing about issues with chrpath and cross-compilers and
32bit objects on 64bit platforms etc. (from this thread), I'm ignorant
on the matter. I don't understand if you're explaining a new issue
with chrpath or something entirely different. IANA chrpath dev.

Also, chrpath is not being relied upon all that much. It's understood
to be a little bit of a hack tool but it does provide _serious_ time
reductions at install time because linking is so expensive for us. As
such, we turn it on when it'll work, turn it off when it won't. Well
worth it.

-- 
Gavin Beatty

SEMPER UBI SUB UBI