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]

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


On Thursday 03 January 2008, Alexander Neundorf wrote:
> 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.

as long as the option is a configure flag of sorts and not enabled by default, 
it should of course be fine.  but if this sort of behavior is turned on all 
the time, you're basically screwing users so developers can be lazy.  this is 
hardly a good trade off, especially considering tools already exist to 
address your needs (libtool).  personally, i havent used x86 as a normal 
platform in years (x86_64/ppc/ppc64 are my main systems).

> 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 a specific example.  multilib refers to any system that natively 
supports multiple ABIs simultaneously.  the much more common example would be 
an x86_64 system that also has x86 libs in place.  if the ELF format 
(bit/endian) is not exactly as the default output, then chrpath doesnt really 
work.  it's the same thing as cross-compiling really, just more likely people 
will have multilib on their system.
-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]