Re: meta-toolchain doesn't compile working binaries

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2014-05-06 at 17:59 -0400, Denys Dmytriyenko wrote:
> On Tue, May 06, 2014 at 04:49:09PM -0500, Mark Hatle wrote:
> > On 5/6/14, 4:44 PM, Denys Dmytriyenko wrote:
> > >On Tue, May 06, 2014 at 04:25:15PM -0500, Mark Hatle wrote:
> > >>On 5/6/14, 3:56 PM, Khem Raj wrote:
> > >>>On Tue, May 6, 2014 at 1:55 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> > >>>>Do you know that OE toolchain is not relocatable?
> > >>>
> > >>>is that true ?
> > >>>
> > >>
> > >>It's the load path of the executables, they use the libc-nativesdk,
> > >>so they need a hard path to the correct ld.so to get started.
> > >
> > >More specifically, it's PT_INTERP section of the ELF header in every binary
> > >that hardcodes the full path to our own dynamic linker/loader (i.e. mentioned
> > >libc-nativesdk). I wish it would support the use of $ORIGIN similar to RPATH
> > >and RUNPATH for libraries, but I bet there are all kinds of corner cases with
> > >that... :)
> > >
> > 
> > $ORIGIN, RPATH and RUNPATH are all implemented by the ld.so, there
> > is no way to dynamically assign the interpreter (ld.so).
> 
> Yes, the above wish was highly abstract and hypothetical and would probably 
> require kernel to support $ORIGIN used in the ELF header... But I'm not 
> suggesting it, just speculating! :)

Right, that would need support in the kernel and would mean that the SDK
was restricted to specific kernel versions.

Having said that, I have wondered if we could see if we could get it in
and then someday remove this restriction.

Cheers,

Richard