[PATCH] uninative: Fix conflicts with normal sysroot

[PATCH] uninative: Fix conflicts with normal sysroot

[Richard Purdie]

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@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)}"
 
 UNINATIVE_URL ?= "unset"
 UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc.tar.bz2"
@@ -41,7 +41,8 @@ python uninative_eventhandler() {
                 fetcher.download()
             except Exception as exc:
                 bb.fatal("Unable to download uninative tarball: %s" % str(exc))
-        cmd = e.data.expand("mkdir -p ${STAGING_DIR}; cd ${STAGING_DIR}; tar -xjf ${UNINATIVE_DLDIR}/${UNINATIVE_TARBALL}; ${STAGING_DIR}/relocate_sdk.py ${STAGING_DIR_NATIVE} ${UNINATIVE_LOADER} ${UNINATIVE_LOADER} ${STAGING_BINDIR_NATIVE}/patchelf-uninative")
+
+        cmd = e.data.expand("mkdir -p ${STAGING_DIR}-uninative; cd ${STAGING_DIR}-uninative; tar -xjf ${UNINATIVE_DLDIR}/${UNINATIVE_TARBALL}; ${STAGING_DIR}-uninative/relocate_sdk.py ${STAGING_DIR}-uninative/${BUILD_ARCH}-linux ${UNINATIVE_LOADER} ${UNINATIVE_LOADER} ${STAGING_DIR}-uninative/${BUILD_ARCH}-linux/patchelf-uninative")
         try:
             subprocess.check_call(cmd, shell=True)
         except subprocess.CalledProcessError as exc:
@@ -51,6 +52,8 @@ python uninative_eventhandler() {
 
 SSTATEPOSTUNPACKFUNCS_append = " uninative_changeinterp"
 
+PATH_prepend = "${STAGING_DIR}-uninative/${BUILD_ARCH}-linux${bindir_native}:"
+
 python uninative_changeinterp () {
     import subprocess
     import stat

Re: [PATCH] uninative: Fix conflicts with normal sysroot

[Mark Hatle]

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@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.

--Mark

>  UNINATIVE_URL ?= "unset"
>  UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc.tar.bz2"
> @@ -41,7 +41,8 @@ python uninative_eventhandler() {
>                  fetcher.download()
>              except Exception as exc:
>                  bb.fatal("Unable to download uninative tarball: %s" % str(exc))
> -        cmd = e.data.expand("mkdir -p ${STAGING_DIR}; cd ${STAGING_DIR}; tar -xjf ${UNINATIVE_DLDIR}/${UNINATIVE_TARBALL}; ${STAGING_DIR}/relocate_sdk.py ${STAGING_DIR_NATIVE} ${UNINATIVE_LOADER} ${UNINATIVE_LOADER} ${STAGING_BINDIR_NATIVE}/patchelf-uninative")
> +
> +        cmd = e.data.expand("mkdir -p ${STAGING_DIR}-uninative; cd ${STAGING_DIR}-uninative; tar -xjf ${UNINATIVE_DLDIR}/${UNINATIVE_TARBALL}; ${STAGING_DIR}-uninative/relocate_sdk.py ${STAGING_DIR}-uninative/${BUILD_ARCH}-linux ${UNINATIVE_LOADER} ${UNINATIVE_LOADER} ${STAGING_DIR}-uninative/${BUILD_ARCH}-linux/patchelf-uninative")
>          try:
>              subprocess.check_call(cmd, shell=True)
>          except subprocess.CalledProcessError as exc:
> @@ -51,6 +52,8 @@ python uninative_eventhandler() {
>  
>  SSTATEPOSTUNPACKFUNCS_append = " uninative_changeinterp"
>  
> +PATH_prepend = "${STAGING_DIR}-uninative/${BUILD_ARCH}-linux${bindir_native}:"
> +
>  python uninative_changeinterp () {
>      import subprocess
>      import stat
> 
> 

Re: [PATCH] uninative: Fix conflicts with normal sysroot

[Richard Purdie]

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@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