[OE-core] [PATCH] uninative: Fix conflicts with normal sysroot

Richard Purdie richard.purdie at linuxfoundation.org
Fri Jan 22 23:18:14 UTC 2016


On Fri, 2016-01-22 at 13:01 -0600, Mark Hatle wrote:
> On 1/22/16 11:17 AM, Richard Purdie wrote:
> > Currently this code installs into the standard sysroot, however
> > this causes
> > some conflicts when linking since the linker can look specifically
> > for
> > versioned .so files (e.g. like libpthreads.so.0). This breaks
> > builds
> > of util-linux-native for example.
> > 
> > The easiest solution is to install uninative into its own separate
> > sysroot.
> > 
> > Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
> > 
> > diff --git a/meta/classes/uninative.bbclass
> > b/meta/classes/uninative.bbclass
> > index fe1e89b..8686159 100644
> > --- a/meta/classes/uninative.bbclass
> > +++ b/meta/classes/uninative.bbclass
> > @@ -1,6 +1,6 @@
> >  NATIVELSBSTRING = "universal"
> >  
> > -UNINATIVE_LOADER ?= "${@bb.utils.contains('BUILD_ARCH', 'x86_64',
> > '${STAGING_DIR_NATIVE}/lib/ld-linux-x86-64.so.2',
> > '${STAGING_DIR_NATIVE}/lib/ld-linux.so.2', d)}"
> > +UNINATIVE_LOADER ?= "${STAGING_DIR}-uninative/${BUILD_ARCH}-linux/
> > lib/${@bb.utils.contains('BUILD_ARCH', 'x86_64', 'ld-linux-x86
> > -64.so.2', 'ld-linux.so.2', d)}"
> 
> Have you considered changing the name of the ld.so for the uninative
> so that
> there is no way it can conflict with the host system.
> 
> This would require a minor patch to the uninative linker/compiler to
> use the new
> name -- and of course above to know it as well.
> 
> This might be a useful safety to prevent the system from every
> falling back to
> the /lib/... version.

The problem wasn't/isn't ld.so. Its that ${STAGING_DIR_NATIVE}/lib/ is
in the linker paths for -native utils and it was picking up random
pieces of the libc from there like libpthread, even though there was
only versioned .so files there, no .so links. It was those that
conflicted with the host system.

The ld.so references are in the interpreter sections of the binaries so
very hard to get confused and I'm not aware of any issue there, nor can
I really envisage one.

So whilst I appreciate the idea, I'm not sure it solves any issue we
have...

Cheers,

Richard



More information about the Openembedded-core mailing list