13937 2020-06-11 03:18:22 +0000 llvm-config does not work any more with multilib 2020-11-19 16:16:11 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain unspecified x86 Multiple RESOLVED FIXED backport 3.1 Medium+ normal 3.2 M4 1 ydirson ydirson meta.mr.watcher meta.watcher randy.macleod richard.purdie --- --- Don't know oldest_to_newest 87458 0 ydirson 2020-06-11 03:18:22 +0000 In dunfell, when using multilib, llvm-config looks for libs in usr/lib and fails: # $LLVM_CONFIG --shared-mode llvm-config: error: component libraries and shared library llvm-config: error: missing: /home/yann/yocto/meta-blade/meta-shadow-os/build-boxv1-dunfell/tmp/work/dbfp4-shadow-linux/mesa/2_20.0.2-r0/recipe-sysroot/usr/lib/llvm9.0.1/libLLVMDemangle.a ... llvm-config: error: missing: /home/yann/yocto/meta-blade/meta-shadow-os/build-boxv1-dunfell/tmp/work/dbfp4-shadow-linux/mesa/2_20.0.2-r0/recipe-sysroot/usr/lib/llvm9.0.1/libLLVMXRay.a # echo $? 1 This in turn causes an obscure exception in meson when trying to configure mesa. Looks like the YOCTO_ALTERNATE_EXE_PATH patch has become insufficient, llvm-config insists on using "$whatever/lib/llvm9.0.1/". 87459 1 ydirson 2020-06-11 03:37:57 +0000 Looks like they have a LLVM_LIBDIR_SUFFIX setable on meson command line, to cope with this naming scheme, but then it's dating back to 2014. Not sure why it breaks with dunfell and works with warrior... 87461 2 randy.macleod 2020-06-11 07:48:38 +0000 Are you doing to encounter the llvm-config error? Is that normally built? Maybe you can provide full build steps. 87471 3 richard.purdie 2020-06-11 14:20:20 +0000 "[OE-core] [PATCH] meson: backport library ordering fix" might fix this? 87522 4 ydirson 2020-06-19 07:12:59 +0000 I updated meson to the version that adds this fix master to master, but the problem is still there. As for how it is built, I "just" use our custom not-public-yet layer, which includes pieces of meta-amd (they have dropped support for amdfalconx86 long ago, and we need their packaging changes to allow building both the VA state tracker and va-x11). I'll try reproduce with a minimal deviation from poky. 87546 5 ydirson 2020-06-23 05:34:26 +0000 Submitted https://github.com/mesonbuild/meson/issues/7371 for meson bombing out instead of catching the error. The OE-level issue is only that llvm-config does not grok multi-lib. The problem triggers when PACKAGECONFIG "gallium-llvm" is activated on mesa, and multilib is active. It can be reproduced in a dunfell poky build for a qemux86-64 target, by adding this to local.conf: DISTRO_FEATURES_remove = "wayland nfs irda pcmcia usbgadget 3g nfc ptest bluetooth bluez5" DISTRO_FEATURES += "x11 opengl" PACKAGECONFIG_append_pn-mesa = " gallium-llvm" MULTILIBS ?= "" require conf/multilib.conf There is a patch in meta-amd that seems to address this: https://git.yoctoproject.org/cgit/cgit.cgi/meta-amd/tree/meta-amd-bsp/recipes-core/llvm/llvm/0002-llvm-allow-env-override-of-exe-path.patch However, it does not seem to be sufficient, digging. 87571 6 ydirson 2020-06-24 11:28:43 +0000 Error on my seide, the patch in meta-amd works perfectly. 88634 7 randy.macleod 2020-11-19 16:16:11 +0000 Looks like this was fixed in meson so closing. If it's still affecting master or a release, please re-open and/or send a fix to the list.