[PATCH v2 1/4] native bbclass: handle base_libdir as well

[PATCH v2 1/4] native bbclass: handle base_libdir as well

[Koen Kooi]

Native.bbclass needs to fixup both base_libdir and libdir to handle things like multiarch. This fixes wic and ext4.* image failures during do_rootfs where mkfs.ext4 can't find its libraries.

Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
---
 meta/classes/native.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index a911f2a..7f2df17 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -78,6 +78,7 @@ exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
 
 bindir = "${STAGING_BINDIR_NATIVE}"
 sbindir = "${STAGING_SBINDIR_NATIVE}"
+base_libdir = "${STAGING_LIBDIR_NATIVE}"
 libdir = "${STAGING_LIBDIR_NATIVE}"
 includedir = "${STAGING_INCDIR_NATIVE}"
 sysconfdir = "${STAGING_ETCDIR_NATIVE}"
@@ -89,6 +90,7 @@ export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} ${base_libdir} /lib /lib64
 
 NATIVE_PACKAGE_PATH_SUFFIX ?= ""
 bindir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
+base_libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libexecdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 
-- 
2.9.5

[PATCH v2 2/4] libcap: fix (base_)libdir usage

[Koen Kooi]

The recipe wants to install libs into base_libdir, but uses "basename $libdir" to derive that. That breaks in a multiarch setup. Use the proper variable and remove the inline python usage.

Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
---
 meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/libcap/libcap_2.25.bb b/meta/recipes-support/libcap/libcap_2.25.bb
index d619a2e..47ecf34 100644
--- a/meta/recipes-support/libcap/libcap_2.25.bb
+++ b/meta/recipes-support/libcap/libcap_2.25.bb
@@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
 
 EXTRA_OEMAKE = " \
   INDENT=  \
-  lib=${@os.path.basename('${libdir}')} \
+  lib='${base_libdir}' \
   RAISE_SETFCAP=no \
   DYNAMIC=yes \
   BUILD_GPERF=yes \
-- 
2.9.5

[PATCH v2 3/4] bind: fix openSSL detection when using multiarch

[Koen Kooi]

In multiarch /usr/include and /usr/lib/<tuple/ are not on the same level anymore. This change will pass a correct includedir, but a wrong libdir, but the linker picks it up anyway.

Tested on multiarch and regular build.

Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
---
 meta/recipes-connectivity/bind/bind_9.10.6.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bind/bind_9.10.6.bb b/meta/recipes-connectivity/bind/bind_9.10.6.bb
index 8b8835b..20c8d7b 100644
--- a/meta/recipes-connectivity/bind/bind_9.10.6.bb
+++ b/meta/recipes-connectivity/bind/bind_9.10.6.bb
@@ -35,7 +35,7 @@ EXTRA_OECONF = " ${ENABLE_IPV6} --with-libtool --enable-threads \
                  --disable-devpoll --enable-epoll --with-gost=no \
                  --with-gssapi=no --with-ecdsa=yes \
                  --sysconfdir=${sysconfdir}/bind \
-                 --with-openssl=${STAGING_LIBDIR}/.. \
+                 --with-openssl=${STAGING_DIR_HOST}${prefix} \
                "
 
 inherit autotools update-rc.d systemd useradd pkgconfig python3-dir
-- 
2.9.5

[PATCH v2 4/4] python 2.7: fix multilib patch to accept multiarch style paths

[Koen Kooi]

Using 'basename' to strip the prefix fails when using multiarch style paths.

Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
---
 meta/recipes-devtools/python/python.inc            | 6 ++++++
 meta/recipes-devtools/python/python/multilib.patch | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python.inc b/meta/recipes-devtools/python/python.inc
index 979b601..84bcb6a 100644
--- a/meta/recipes-devtools/python/python.inc
+++ b/meta/recipes-devtools/python/python.inc
@@ -33,6 +33,12 @@ EXTRA_OECONF = "\
   ${PYTHONLSBOPTS} \
 "
 
+do_configure_prepend() {
+	libdirleaf="$(echo ${libdir} | sed -e 's:${prefix}/::')"
+	sed -i -e "s:SEDMELIBLEAF:${libdirleaf}:g" \
+		${S}/configure.ac
+}
+
 do_install_append () {
 	sed -i -e 's:${HOSTTOOLS_DIR}/install:install:g' \
 		-e 's:${HOSTTOOLS_DIR}/mkdir:mkdir:g' \
diff --git a/meta/recipes-devtools/python/python/multilib.patch b/meta/recipes-devtools/python/python/multilib.patch
index 1116dd5..d24bc15 100644
--- a/meta/recipes-devtools/python/python/multilib.patch
+++ b/meta/recipes-devtools/python/python/multilib.patch
@@ -11,7 +11,7 @@ Index: Python-2.7.14/configure.ac
  
 +AC_SUBST(LIB)
 +AC_MSG_CHECKING(LIB)
-+LIB=`basename ${libdir}`
++LIB="SEDMELIBLEAF"
 +AC_MSG_RESULT($LIB)
  
  AC_SUBST(LIBRARY)
-- 
2.9.5

Re: [PATCH v2 2/4] libcap: fix (base_)libdir usage

[Ricardo Salveti]

On Mon, Apr 16, 2018 at 10:00 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> The recipe wants to install libs into base_libdir, but uses "basename $libdir" to derive that. That breaks in a multiarch setup. Use the proper variable and remove the inline python usage.
>
> Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
> ---
>  meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/libcap/libcap_2.25.bb b/meta/recipes-support/libcap/libcap_2.25.bb
> index d619a2e..47ecf34 100644
> --- a/meta/recipes-support/libcap/libcap_2.25.bb
> +++ b/meta/recipes-support/libcap/libcap_2.25.bb
> @@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
>
>  EXTRA_OEMAKE = " \
>    INDENT=  \
> -  lib=${@os.path.basename('${libdir}')} \
> +  lib='${base_libdir}' \
>    RAISE_SETFCAP=no \
>    DYNAMIC=yes \
>    BUILD_GPERF=yes \

This creates a build failure when usrmerge is used, as libcap expects
only the lib folder name and not the lib path (and when usrmerge is
enabled base_libdir gets set to /usr/lib instead of /lib).

Since base_libdir and libdir are all based out baselib, can you
provide more details about how that broke your multiarch setup?

The failure when usrmerge is used:
WARNING: libcap-2.25-r0 do_package: QA Issue: libcap:
Files/directories were installed but not shipped in any package:
  /usr/lib
  /usr/usr/lib/libcap.so
  /usr/usr/lib/libcap.so.2
  /usr/usr/lib/libcap.so.2.25
  /usr/usr/lib/libcap.a
  /usr/usr/lib/pkgconfig
  /usr/usr/lib/pkgconfig/libcap.pc
  /usr/usr/lib/security/pam_cap.so

Thanks,
-- 
Ricardo Salveti de Araujo

Re: [PATCH v2 2/4] libcap: fix (base_)libdir usage

[Mark Asselstine]

On Tuesday, May 8, 2018 1:46:43 PM EDT Ricardo Salveti wrote:
> On Mon, Apr 16, 2018 at 10:00 AM, Koen Kooi <koen@dominion.thruhere.net> 
wrote:
> > The recipe wants to install libs into base_libdir, but uses "basename
> > $libdir" to derive that. That breaks in a multiarch setup. Use the proper
> > variable and remove the inline python usage.
> > 
> > Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
> > ---
> > 
> >  meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-support/libcap/libcap_2.25.bb
> > b/meta/recipes-support/libcap/libcap_2.25.bb index d619a2e..47ecf34
> > 100644
> > --- a/meta/recipes-support/libcap/libcap_2.25.bb
> > +++ b/meta/recipes-support/libcap/libcap_2.25.bb
> > @@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
> > 
> >  EXTRA_OEMAKE = " \
> >  
> >    INDENT=  \
> > 
> > -  lib=${@os.path.basename('${libdir}')} \
> > +  lib='${base_libdir}' \
> > 
> >    RAISE_SETFCAP=no \
> >    DYNAMIC=yes \
> >    BUILD_GPERF=yes \
> 
> This creates a build failure when usrmerge is used, as libcap expects
> only the lib folder name and not the lib path (and when usrmerge is
> enabled base_libdir gets set to /usr/lib instead of /lib).
> 
> Since base_libdir and libdir are all based out baselib, can you
> provide more details about how that broke your multiarch setup?
> 
> The failure when usrmerge is used:
> WARNING: libcap-2.25-r0 do_package: QA Issue: libcap:
> Files/directories were installed but not shipped in any package:
>   /usr/lib
>   /usr/usr/lib/libcap.so
>   /usr/usr/lib/libcap.so.2
>   /usr/usr/lib/libcap.so.2.25
>   /usr/usr/lib/libcap.a
>   /usr/usr/lib/pkgconfig
>   /usr/usr/lib/pkgconfig/libcap.pc
>   /usr/usr/lib/security/pam_cap.so

Agreed. I just started to determine how this is breaking qemu-native (with 
virtfs enabled in the PACKAGECONFIG) and found that this change drops several 
files from being installed in the native-sysroot.

Before this change:
⟫ cat .../tmp/work/x86_64-linux/qemu-native/2.11.1-r0/recipe-sysroot-native/
installeddeps/libcap-native.39df7fd64afdeb62b13bb47b7969532b 
recipe-sysroot-native/sysroot-providers/libcap-native
recipe-sysroot-native/usr/include/sys/capability.h
recipe-sysroot-native/usr/sbin/getpcaps
recipe-sysroot-native/usr/sbin/capsh
recipe-sysroot-native/usr/sbin/getcap
recipe-sysroot-native/usr/sbin/setcap
recipe-sysroot-native/usr/lib/libcap.so
recipe-sysroot-native/usr/lib/libcap.so.2.25
recipe-sysroot-native/usr/lib/libcap.a
recipe-sysroot-native/usr/lib/libcap.so.2
recipe-sysroot-native/usr/lib/pkgconfig/libcap.pc
recipe-sysroot-native/usr/lib/pkgconfig/
recipe-sysroot-native/sysroot-providers/
recipe-sysroot-native/usr/include/sys/
recipe-sysroot-native/usr/include/
recipe-sysroot-native/usr/share/
recipe-sysroot-native/usr/sbin/
recipe-sysroot-native/usr/lib/
recipe-sysroot-native/usr/

After the change:
⟫ cat .../tmp/work/x86_64-linux/qemu-native/2.11.1-r0/recipe-sysroot-native/
installeddeps/libcap-native.2d12ea82cbd6eeaf25251caae2dce487
recipe-sysroot-native/sysroot-providers/libcap-native
recipe-sysroot-native/usr/include/sys/capability.h
recipe-sysroot-native/usr/sbin/getpcaps
recipe-sysroot-native/usr/sbin/capsh
recipe-sysroot-native/usr/sbin/getcap
recipe-sysroot-native/usr/sbin/setcap
recipe-sysroot-native/sysroot-providers/
recipe-sysroot-native/usr/include/sys/
recipe-sysroot-native/usr/include/
recipe-sysroot-native/usr/share/
recipe-sysroot-native/usr/sbin/
recipe-sysroot-native/usr/lib/
recipe-sysroot-native/usr/

I also believe that the old inline python was also not functioning correctly 
which is why it was believed that the change was non-consequential for non-
multilib builds. I am looking at putting together a fix but would be more than 
happy if someone else came up with something first.

Mark


> 
> Thanks,

Re: [PATCH v2 2/4] libcap: fix (base_)libdir usage

[Mark Asselstine]

On Tuesday, May 8, 2018 2:26:47 PM EDT Mark Asselstine wrote:
> On Tuesday, May 8, 2018 1:46:43 PM EDT Ricardo Salveti wrote:
> > On Mon, Apr 16, 2018 at 10:00 AM, Koen Kooi <koen@dominion.thruhere.net>
> 
> wrote:
> > > The recipe wants to install libs into base_libdir, but uses "basename
> > > $libdir" to derive that. That breaks in a multiarch setup. Use the
> > > proper
> > > variable and remove the inline python usage.
> > > 
> > > Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
> > > ---
> > > 
> > >  meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/meta/recipes-support/libcap/libcap_2.25.bb
> > > b/meta/recipes-support/libcap/libcap_2.25.bb index d619a2e..47ecf34
> > > 100644
> > > --- a/meta/recipes-support/libcap/libcap_2.25.bb
> > > +++ b/meta/recipes-support/libcap/libcap_2.25.bb
> > > @@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
> > > 
> > >  EXTRA_OEMAKE = " \
> > >  
> > >    INDENT=  \
> > > 
> > > -  lib=${@os.path.basename('${libdir}')} \
> > > +  lib='${base_libdir}' \
> > > 
> > >    RAISE_SETFCAP=no \
> > >    DYNAMIC=yes \
> > >    BUILD_GPERF=yes \
> > 
> > This creates a build failure when usrmerge is used, as libcap expects
> > only the lib folder name and not the lib path (and when usrmerge is
> > enabled base_libdir gets set to /usr/lib instead of /lib).
> > 
> > Since base_libdir and libdir are all based out baselib, can you
> > provide more details about how that broke your multiarch setup?
> > 
> > The failure when usrmerge is used:
> > WARNING: libcap-2.25-r0 do_package: QA Issue: libcap:
> > 
> > Files/directories were installed but not shipped in any package:
> >   /usr/lib
> >   /usr/usr/lib/libcap.so
> >   /usr/usr/lib/libcap.so.2
> >   /usr/usr/lib/libcap.so.2.25
> >   /usr/usr/lib/libcap.a
> >   /usr/usr/lib/pkgconfig
> >   /usr/usr/lib/pkgconfig/libcap.pc
> >   /usr/usr/lib/security/pam_cap.so
> 
> Agreed. I just started to determine how this is breaking qemu-native (with
> virtfs enabled in the PACKAGECONFIG) and found that this change drops
> several files from being installed in the native-sysroot.
> 
> Before this change:
> ⟫ cat .../tmp/work/x86_64-linux/qemu-native/2.11.1-r0/recipe-sysroot-native/
> installeddeps/libcap-native.39df7fd64afdeb62b13bb47b7969532b
> recipe-sysroot-native/sysroot-providers/libcap-native
> recipe-sysroot-native/usr/include/sys/capability.h
> recipe-sysroot-native/usr/sbin/getpcaps
> recipe-sysroot-native/usr/sbin/capsh
> recipe-sysroot-native/usr/sbin/getcap
> recipe-sysroot-native/usr/sbin/setcap
> recipe-sysroot-native/usr/lib/libcap.so
> recipe-sysroot-native/usr/lib/libcap.so.2.25
> recipe-sysroot-native/usr/lib/libcap.a
> recipe-sysroot-native/usr/lib/libcap.so.2
> recipe-sysroot-native/usr/lib/pkgconfig/libcap.pc
> recipe-sysroot-native/usr/lib/pkgconfig/
> recipe-sysroot-native/sysroot-providers/
> recipe-sysroot-native/usr/include/sys/
> recipe-sysroot-native/usr/include/
> recipe-sysroot-native/usr/share/
> recipe-sysroot-native/usr/sbin/
> recipe-sysroot-native/usr/lib/
> recipe-sysroot-native/usr/
> 
> After the change:
> ⟫ cat .../tmp/work/x86_64-linux/qemu-native/2.11.1-r0/recipe-sysroot-native/
> installeddeps/libcap-native.2d12ea82cbd6eeaf25251caae2dce487
> recipe-sysroot-native/sysroot-providers/libcap-native
> recipe-sysroot-native/usr/include/sys/capability.h
> recipe-sysroot-native/usr/sbin/getpcaps
> recipe-sysroot-native/usr/sbin/capsh
> recipe-sysroot-native/usr/sbin/getcap
> recipe-sysroot-native/usr/sbin/setcap
> recipe-sysroot-native/sysroot-providers/
> recipe-sysroot-native/usr/include/sys/
> recipe-sysroot-native/usr/include/
> recipe-sysroot-native/usr/share/
> recipe-sysroot-native/usr/sbin/
> recipe-sysroot-native/usr/lib/
> recipe-sysroot-native/usr/
> 
> I also believe that the old inline python was also not functioning correctly
> which is why it was believed that the change was non-consequential for non-
> multilib builds. I am looking at putting together a fix but would be more
> than happy if someone else came up with something first.

Sorry, I stand corrected the python is functional, I was getting confused with 
the interplay between 'lib' used during make and 'prefix' used during install. 

The issue wtih the -native build is that $base_libdir is influenced by 
additions made in native.bbclase, specifically:

    # Path prefixes
    base_prefix = "${STAGING_DIR_NATIVE}"
    prefix = "${STAGING_DIR_NATIVE}${prefix_native}"

Since $base_libdir incorporates $base_prefix:

export base_libdir = "${root_prefix}/${baselib}"
where
root_prefix = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', \
    '${exec_prefix}', '${base_prefix}', d)}"

So we end doubling down $STAGING_DIR_NATIVE twice. Once via 'lib=' in 
do_compile and once via 'prefix=' in do_install.

Similarly with the 'usrmerge' builds, we are doubling down on '/usr', once in 
do_compile and one in do_install.

I will send out a fix but since the original commit doesn't really describe 
the multiarch breakage I will have to rely on Koen to validate that my change 
doesn't just put us back to where we were.

Mark




> 
> Mark
> 
> > Thanks,