Bug 13937

Summary: llvm-config does not work any more with multilib
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Yann Dirson <ydirson>
Component: devtools / tool chainAssignee: Yann Dirson <ydirson>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium+ CC: meta.mr.watcher, meta.watcher, randy.macleod, richard.purdie
Version: unspecified   
Target Milestone: 3.2 M4   
Hardware: x86   
OS: Multiple   
Whiteboard: backport 3.1
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know

Description Yann Dirson 2020-06-11 03:18:22 UTC 
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/".
Comment 1 Yann Dirson 2020-06-11 03:37:57 UTC 
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...
Comment 2 Randy MacLeod 2020-06-11 07:48:38 UTC 
Are you doing to encounter the llvm-config error? Is that normally built? Maybe you can provide full build steps.
Comment 3 Richard Purdie 2020-06-11 14:20:20 UTC 
"[OE-core] [PATCH] meson: backport library ordering fix" might fix this?
Comment 4 Yann Dirson 2020-06-19 07:12:59 UTC 
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.
Comment 5 Yann Dirson 2020-06-23 05:34:26 UTC 
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.
Comment 6 Yann Dirson 2020-06-24 11:28:43 UTC 
Error on my seide, the patch in meta-amd works perfectly.
Comment 7 Randy MacLeod 2020-11-19 16:16:11 UTC 
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.