[RFC] Replacing chrpath with patchelf

[RFC] Replacing chrpath with patchelf

[Khem Raj]

Hi,

I have a patchset that replaces use of chrpath with patchelf. Patchelf can
resize the ELF headers to accomodate larger RPATHs

The branch is posted here

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/patchelf

Please test it out and let me know if you see any issues

-Khem

Re: [RFC] Replacing chrpath with patchelf

[Richard Purdie]

On Sat, 2012-08-18 at 00:17 -0700, Khem Raj wrote:
> Hi,
> 
> I have a patchset that replaces use of chrpath with patchelf. Patchelf can
> resize the ELF headers to accomodate larger RPATHs
> 
> The branch is posted here
> 
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/patchelf
> 
> Please test it out and let me know if you see any issues

chrpath is something we require users to install on the system they're
building on. The reason is that we need to relocate the native recipes
and you can't do that without chrpath. You can't build chrpath without
building a native recipe you need to stage to change its own RPATH. 

Now there are a variety of ways we can deal with this but we need to
think it through.

At the very least such a change would need to adjust all the
documentation about the prerequisites.

I'm not actually sure we need to deal with larger RPATHs in the real
world either. There are some bugs we're finding now the call is failing
but they're not turning out to be due to that.

Cheers,

Richard

Re: [RFC] Replacing chrpath with patchelf

[Khem Raj]

On Sat, Aug 18, 2012 at 3:31 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Sat, 2012-08-18 at 00:17 -0700, Khem Raj wrote:
>> Hi,
>>
>> I have a patchset that replaces use of chrpath with patchelf. Patchelf can
>> resize the ELF headers to accomodate larger RPATHs
>>
>> The branch is posted here
>>
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/patchelf
>>
>> Please test it out and let me know if you see any issues
>
> chrpath is something we require users to install on the system they're
> building on. The reason is that we need to relocate the native recipes
> and you can't do that without chrpath. You can't build chrpath without
> building a native recipe you need to stage to change its own RPATH.
>

so I figured. which now means you need to have patchelf on build host
preinstalled instead of chrpath.

> Now there are a variety of ways we can deal with this but we need to
> think it through.
>
> At the very least such a change would need to adjust all the
> documentation about the prerequisites.

Yes. I tried to document it through an elaborate message
from sanity.bbclass about prerequisites and needs documentation
adjustments yes.

>
> I'm not actually sure we need to deal with larger RPATHs in the real
> world either. There are some bugs we're finding now the call is failing
> but they're not turning out to be due to that.

you never know. It just lifts this limitation. We ship
chrpath-nativesdk as well and people can use it in different ways

>
> Cheers,
>
> Richard
>

Re: [RFC] Replacing chrpath with patchelf

[Phil Blundell]

On Sat, 2012-08-18 at 10:15 -0700, Khem Raj wrote:
> so I figured. which now means you need to have patchelf on build host
> preinstalled instead of chrpath.

That'd be a bit of a pain, since (afaict) patchelf is not so widely
available in host distributions as chrpath.

> you never know. It just lifts this limitation. We ship
> chrpath-nativesdk as well and people can use it in different ways

I agree that removing the weird and arbitrary-seeming (from the user
perspective) restriction on rpath length would be a good thing.  But
it's less clear that swapping a weird restriction that few people will
ever run into for a requirement to pre-install a relatively obscure host
binary on all systems is a good tradeoff.

How about writing a python function, or a trivial standalone program
(which can be compiled -native without requiring anything other than
${BUILD_CC}) to preprocess the binaries before chrpath sees them, or
indeed just to replace chrpath altogether?  Or, as an alternative, how
about fixing chrpath to suck less and then just waiting for the improved
version to trickle down into deployed host distributions?

p.

Re: [RFC] Replacing chrpath with patchelf

[Khem Raj]

On Sat, Aug 18, 2012 at 6:27 PM, Phil Blundell <philb@gnu.org> wrote:
> On Sat, 2012-08-18 at 10:15 -0700, Khem Raj wrote:
>> so I figured. which now means you need to have patchelf on build host
>> preinstalled instead of chrpath.
>
> That'd be a bit of a pain, since (afaict) patchelf is not so widely
> available in host distributions as chrpath.
>
>> you never know. It just lifts this limitation. We ship
>> chrpath-nativesdk as well and people can use it in different ways
>
> I agree that removing the weird and arbitrary-seeming (from the user
> perspective) restriction on rpath length would be a good thing.  But
> it's less clear that swapping a weird restriction that few people will
> ever run into for a requirement to pre-install a relatively obscure host
> binary on all systems is a good tradeoff.

patchelf does have packages for all familiar linux distros but its not in
their default feeds. May be it will be nicer to create one meta
package which installs
all prerequisites not only chrpath/patchelf and maintain that ourselves
this could be nicer since then user only installs

apt-get install make-my-host-compile-oe package on ubuntu and similar
for others.

>
> How about writing a python function, or a trivial standalone program
> (which can be compiled -native without requiring anything other than
> ${BUILD_CC}) to preprocess the binaries before chrpath sees them, or
> indeed just to replace chrpath altogether?  Or, as an alternative, how
> about fixing chrpath to suck less and then just waiting for the improved
> version to trickle down into deployed host distributions?
>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [RFC] Replacing chrpath with patchelf

[Burton, Ross]

On 22 August 2012 01:21, Khem Raj <raj.khem@gmail.com> wrote:
> May be it will be nicer to create one meta
> package which installs
> all prerequisites not only chrpath/patchelf and maintain that ourselves
> this could be nicer since then user only installs
>
> apt-get install make-my-host-compile-oe package on ubuntu and similar
> for others.

I used to maintain one of these for Debian years ago, and it did help a lot.

Ross

Re: [RFC] Replacing chrpath with patchelf

[Richard Purdie]

On Wed, 2012-08-22 at 08:47 +0100, Burton, Ross wrote:
> On 22 August 2012 01:21, Khem Raj <raj.khem@gmail.com> wrote:
> > May be it will be nicer to create one meta
> > package which installs
> > all prerequisites not only chrpath/patchelf and maintain that ourselves
> > this could be nicer since then user only installs
> >
> > apt-get install make-my-host-compile-oe package on ubuntu and similar
> > for others.
> 
> I used to maintain one of these for Debian years ago, and it did help a lot.

These days I'd much rather just ship a tarball with all the bits needed
contained therein. Since we can self-host and we have the nativesdk
infrastructure, this shouldn't be hard and it would work on any distro.

Cheers,

Richard