uninative: Fix conflicts with normal sysroot

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 <[email protected]>

meta/classes/uninative.bbclass +0 -0

index fe1e89b..8686159 100644

meta/classes/uninative.bbclass +4 -1

 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

Quoted 23 lines · 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 <[email protected]>

meta/classes/uninative.bbclass +0 -1

index fe1e89b..8686159 100644
@@ -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',

Quoted 4 lines

'${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.