Uninative for i386 native tool?

Uninative for i386 native tool?

[Chris Laplante]

We have a vendor-provided cross-compiler toolchain that is distributed as 32-bit binaries. Naturally on my native system (outside of Yocto) I can run them by first adding the i386 architecture to dpkg, and then doing "apt-get install -y libc6-dbg:i386 lib32stdc++6 libzstd1:i386 libncurses5:i386" or similar.

Outside of Yocto (a normal terminal):
____
ldd recipe-sysroot-native/usr/bin/my-tool:
	linux-gate.so.1 =>  (0xf7f03000)
	libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf7d48000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7cf3000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7cd6000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7b20000)
	/home/laplante/yocto/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib/ld-linux.so.2 (0xf7f05000)
____



But in a Yocto devshell:
____
ldd recipe-sysroot-native/usr/bin/my-tool:
	not a dynamic executable
____

Is there a way to get this working in Yocto? I assume it has something to do with uninative?

Thanks,
Chris

Re: [OE-core] Uninative for i386 native tool?

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

One possible work around which I'm using for some prebuilt native binaries
is to call them with hosts loader (e.g. /lib32/ld-linux.so.2
${STAGING_BINDIR_NATIVE}/my-tool params)

On Sun, Apr 19, 2020 at 10:37 PM Chris Laplante via lists.openembedded.org
<chris.laplante=agilent.com@lists.openembedded.org> wrote:

> We have a vendor-provided cross-compiler toolchain that is distributed as
> 32-bit binaries. Naturally on my native system (outside of Yocto) I can run
> them by first adding the i386 architecture to dpkg, and then doing "apt-get
> install -y libc6-dbg:i386 lib32stdc++6 libzstd1:i386 libncurses5:i386" or
> similar.
>
> Outside of Yocto (a normal terminal):
> ____
> ldd recipe-sysroot-native/usr/bin/my-tool:
>         linux-gate.so.1 =>  (0xf7f03000)
>         libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6
> (0xf7d48000)
>         libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7cf3000)
>         libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7cd6000)
>         libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7b20000)
>
> /home/laplante/yocto/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
> => /lib/ld-linux.so.2 (0xf7f05000)
> ____
>
>
>
> But in a Yocto devshell:
> ____
> ldd recipe-sysroot-native/usr/bin/my-tool:
>         not a dynamic executable
> ____
>
> Is there a way to get this working in Yocto? I assume it has something to
> do with uninative?
>
> Thanks,
> Chris
> 
>

[-- Attachment #2: Type: text/html, Size: 1917 bytes --]

Re: [OE-core] Uninative for i386 native tool?

[Chris Laplante]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

One possible work around which I'm using for some prebuilt native binaries is to call them with hosts loader (e.g. /lib32/ld-linux.so.2 ${STAGING_BINDIR_NATIVE}/my-tool params)

Ooh, nice. Thanks for the tip! Definitely curious about a longer-term workaround but this is good for the short term.

Thanks again,
Chris

[-- Attachment #2: Type: text/html, Size: 2606 bytes --]

Re: [OE-core] Uninative for i386 native tool?

[Richard Purdie]

On Sun, 2020-04-19 at 21:58 +0000, Chris Laplante via
lists.openembedded.org wrote:
> One possible work around which I'm using for some prebuilt native
> binaries is to call them with hosts loader (e.g. /lib32/ld-linux.so.2 
> ${STAGING_BINDIR_NATIVE}/my-tool params)
>  
> Ooh, nice. Thanks for the tip! Definitely curious about a longer-term 
> workaround but this is good for the short term.  

I suspect uninative assumes all binaries are for the main system
architecture so its probably trying to change the interpreter to a 64
bit one which clearly won't work in this case.

It would be a question of stopping it for these binaries somehow...

Cheers,

Richard

Re: [OE-core] Uninative for i386 native tool?

[Chris Laplante]

> I suspect uninative assumes all binaries are for the main system architecture
> so its probably trying to change the interpreter to a 64 bit one which clearly
> won't work in this case.
> 
> It would be a question of stopping it for these binaries somehow...

Maybe a matter of doing something like UNINATIVE_LOADER_pn-my-tool = "???"

Where "???" would be the loader in a hypothetical i386 uninative. 

Chris 

Re: [OE-core] Uninative for i386 native tool?

[Chris Laplante]

> > I suspect uninative assumes all binaries are for the main system
> > architecture so its probably trying to change the interpreter to a 64
> > bit one which clearly won't work in this case.
> >
> > It would be a question of stopping it for these binaries somehow...
> 
> Maybe a matter of doing something like UNINATIVE_LOADER_pn-my-tool =
> "???"
> 
> Where "???" would be the loader in a hypothetical i386 uninative.

Or I suppose the existing i686 uninative. So the trick would be to get uninative.bbclass to fetch both. 

Re: [OE-core] Uninative for i386 native tool?

[Richard Purdie]

On Mon, 2020-04-20 at 13:56 +0000, chris.laplante@agilent.com wrote:
> > I suspect uninative assumes all binaries are for the main system
> > architecture
> > so its probably trying to change the interpreter to a 64 bit one
> > which clearly
> > won't work in this case.
> > 
> > It would be a question of stopping it for these binaries somehow...
> 
> Maybe a matter of doing something like UNINATIVE_LOADER_pn-my-tool =
> "???"

If only life were that simple.

> Where "???" would be the loader in a hypothetical i386 uninative. 

There is a non-hypothetical i386 loader, it already exists.
Unfortunately the loader has to be downloaded and extracted in place
before anything gets run so it all happens very early. Its done
centrally with one uninative, not two or per recipe.

I think you might be able to do something like:

SSTATEPOSTUNPACKFUNCS_remove_pn-mytool = "uninative_changeinterp"

and it may at least stop breaking it...

Cheers,

Richard

Re: [OE-core] Uninative for i386 native tool?

[Adrian Bunk]

On Sun, Apr 19, 2020 at 11:15:55PM +0100, Richard Purdie wrote:
> On Sun, 2020-04-19 at 21:58 +0000, Chris Laplante via
> lists.openembedded.org wrote:
> > One possible work around which I'm using for some prebuilt native
> > binaries is to call them with hosts loader (e.g. /lib32/ld-linux.so.2 
> > ${STAGING_BINDIR_NATIVE}/my-tool params)
> >  
> > Ooh, nice. Thanks for the tip! Definitely curious about a longer-term 
> > workaround but this is good for the short term.  
> 
> I suspect uninative assumes all binaries are for the main system
> architecture so its probably trying to change the interpreter to a 64
> bit one which clearly won't work in this case.
> 
> It would be a question of stopping it for these binaries somehow...

uninative is default but optional, would
  INHERIT_remove = "uninative"
solve this problem?

> Cheers,
> 
> Richard

cu
Adrian

Re: [OE-core] Uninative for i386 native tool?

[Chris Laplante]

> There is a non-hypothetical i386 loader, it already exists.
> Unfortunately the loader has to be downloaded and extracted in place
> before anything gets run so it all happens very early. Its done centrally with
> one uninative, not two or per recipe.
> 
> I think you might be able to do something like:
> 
> SSTATEPOSTUNPACKFUNCS_remove_pn-mytool = "uninative_changeinterp"
> 
> and it may at least stop breaking it...

What if we taught uninative how to identify whether it is appropriate to change the loader for the executable? If not, it could (maybe configurably) avoid doing so and/or give a warning.  

Chris 

Re: [OE-core] Uninative for i386 native tool?

[Richard Purdie]

On Mon, 2020-04-20 at 15:15 +0000, chris.laplante@agilent.com wrote:
> > There is a non-hypothetical i386 loader, it already exists.
> > Unfortunately the loader has to be downloaded and extracted in
> > place
> > before anything gets run so it all happens very early. Its done
> > centrally with
> > one uninative, not two or per recipe.
> > 
> > I think you might be able to do something like:
> > 
> > SSTATEPOSTUNPACKFUNCS_remove_pn-mytool = "uninative_changeinterp"
> > 
> > and it may at least stop breaking it...
> 
> What if we taught uninative how to identify whether it is appropriate
> to change the loader for the executable? If not, it could (maybe
> configurably) avoid doing so and/or give a warning.  

These are all options, I'm mainly worried about significantly
complicating an already fragile piece of code. It was implemented as a
proof of concept with a plan to go back and put proper hooks into
bitbake to drive it. It worked well enough that nobody has gone back
and done that work. I worry about performance implications too...

Cheers,

Richard