[OE-core] [PATCH 2/3] bind: fix openSSL detection when using multiarch

Koen Kooi koen at dominion.thruhere.net
Wed Apr 11 09:25:38 UTC 2018



> Op 9 apr. 2018, om 18:36 heeft Richard Purdie <richard.purdie at 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 at 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 at 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


More information about the Openembedded-core mailing list