[PATCH 1/3] libcap: fix (base_)libdir usage

[PATCH 1/3] 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 2/3] 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

Re: [PATCH 2/3] bind: fix openSSL detection when using multiarch

[Richard Purdie]

On Mon, 2018-04-09 at 13:56 +0200, Koen Kooi wrote:
> 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.

How far off working is mulitarch for OE-Core?

The reason I ask is I'd like to understand the scope of the changes
needed to support it. It also influences whether these are sumo or post
2.5 changes.

Cheers,

Richard

Re: [PATCH 2/3] bind: fix openSSL detection when using multiarch

[Koen Kooi]

> Op 9 apr. 2018, om 18:36 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> 
> On Mon, 2018-04-09 at 13:56 +0200, Koen Kooi wrote:
>> 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.
> 
> How far off working is mulitarch for OE-Core?

With the current state of OE-core ‘bitbake bash’ does the right things. I have a few patches that make more things work, but those need more testing.

> The reason I ask is I'd like to understand the scope of the changes
> needed to support it. It also influences whether these are sumo or post
> 2.5 changes.

So far all the changes are real bugfixes, like stopping recipes from doing  ‘basename libdir’ to get base_libdir. For things like python I’m running into problems where upstream does the right thing, but the OE multilib patches break that.

There is one change that will need careful consideration if it is meant for sumo, it looks like the sysroot code treats libdir differently from base_libdir:

	[koen@fedora-vm build-rpb]$ ls tmp-rpb-glibc/work/dragonboard_410c-linaro-linux/rpb-console-image/1.0-r0/recipe-sysroot-native/lib/
	x86_64-linux

	[koen@fedora-vm build-rpb]$ ls tmp-rpb-glibc/work/dragonboard_410c-linaro-linux/rpb-console-image/1.0-r0/recipe-sysroot-native/usr/lib/
	aarch64-linaro-linux   libcomps.so                libexpat.a          libgdbm_compat.so             libgthread-2.0.so.0.5400.3  libmpc.so.3.1.0           libparted-fs-resize.so.0.0.1  libpython3.so          libtermcap.so
	[..]
	libcheck.so.0.0.0      libelf.so.1                libgdbm_compat.a    libgthread-2.0.so.0           libmpc.so.3                 libparted-fs-resize.so.0  libpython3.5m.so.1.0          libssl.so.1.0.2

E2fsprogs installs into base_libdir, which gets the multiarch treatment, and mkfs.ext4 fails to find its libs during image generation. 

Regardless of all that, <start handwaving> a lot <stop handwaving> of recipes will need packaging fixes, which should not go into a release branch like sumo, so, personally, I’d move it post sumo.

regards,

Koen

Re: [PATCH 2/3] bind: fix openSSL detection when using multiarch

[Koen Kooi]

> Op 11 apr. 2018, om 11:25 heeft Koen Kooi <koen@dominion.thruhere.net> het volgende geschreven:

[..]

> There is one change that will need careful consideration if it is meant for sumo, it looks like the sysroot code treats libdir differently from base_libdir:
> 
> 	[koen@fedora-vm build-rpb]$ ls tmp-rpb-glibc/work/dragonboard_410c-linaro-linux/rpb-console-image/1.0-r0/recipe-sysroot-native/lib/
> 	x86_64-linux
> 
> 	[koen@fedora-vm build-rpb]$ ls tmp-rpb-glibc/work/dragonboard_410c-linaro-linux/rpb-console-image/1.0-r0/recipe-sysroot-native/usr/lib/
> 	aarch64-linaro-linux   libcomps.so                libexpat.a          libgdbm_compat.so             libgthread-2.0.so.0.5400.3  libmpc.so.3.1.0           libparted-fs-resize.so.0.0.1  libpython3.so          libtermcap.so
> 	[..]
> 	libcheck.so.0.0.0      libelf.so.1                libgdbm_compat.a    libgthread-2.0.so.0           libmpc.so.3                 libparted-fs-resize.so.0  libpython3.5m.so.1.0          libssl.so.1.0.2
> 
> E2fsprogs installs into base_libdir, which gets the multiarch treatment, and mkfs.ext4 fails to find its libs during image generation. 

The assumption seems to have been correct, trying a build with this change:

[koen@fedora-vm openembedded-core]$ git diff
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}"
 


regards,

Koen

[PATCH 3/3] 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/multilib.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python/multilib.patch b/meta/recipes-devtools/python/python/multilib.patch
index 1116dd5..3577eda 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=`echo ${libdir} | sed -e 's:${prefix}::'`
 +AC_MSG_RESULT($LIB)
  
  AC_SUBST(LIBRARY)
-- 
2.9.5

Re: [PATCH 3/3] python 2.7: fix multilib patch to accept multiarch style paths

[Koen Kooi]

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

Please ignore "[PATCH 3/3] python 2.7: fix multilib patch to accept
multiarch style paths" for now, a rebuild from scratch shows a build
failure :/

2018-04-09 13:56 GMT+02:00 Koen Kooi <koen@dominion.thruhere.net>:
>
> 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/multilib.patch | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/python/python/multilib.patch
b/meta/recipes-devtools/python/python/multilib.patch
> index 1116dd5..3577eda 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=`echo ${libdir} | sed -e 's:${prefix}::'`
>  +AC_MSG_RESULT($LIB)
>
>   AC_SUBST(LIBRARY)
> --
> 2.9.5
>

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

Re: [PATCH 1/3] libcap: fix (base_)libdir usage

[Burton, Ross]

This is breaking libcap-native:

| mv: cannot stat
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/x86_64-linux/libcap-native/2.25-r0/image/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/x86_64-linux/libcap-native/2.25-r0/recipe-sysroot-native/usr/lib/libcap*':
No such file or directory

Ross

On 9 April 2018 at 12:56, 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 \
> --
> 2.9.5
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core