Re: [PATCH] llvm: fix native llvm-config RUNPATH

["Vincent Davis Jr" <vince@underview.tech>]

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

Hey,

Desired outcome is for mesa meson configure to succeeded by updating
RUNPATH on llvm-config native binary required by mesa when gallium-llvm
included. When running bitbake -c devshell mesa. Then chrpath -l on llvm-config

Should return on TARGET_ARCH x86_64
$ORIGIN/../lib64:$ORIGIN/../../lib64
not
$ORIGIN/../lib:$ORIGIN/../../lib

SNAPSHOT OF FAILURE
*************************************************************************************************************************
File "/../../../mesa/<version>/recipe-sysroot-native/usr/lib/python3.11/re/__init__.py", line 223, in finditer
return _compile(pattern, flags).finditer(string)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: expected string or bytes-like object, got 'NoneType'
*************************************************************************************************************************

Reason for above failure, at least for me, when TARGET_ARCH = x86_64 you run into
bellow when running llvm-config --help or variant commands directly.

llvm-config: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

Because of that when mesa configure executes llvm-config --version the string is not returned. Thus, leading
to above error.

If you run chrpath -l on llvm-config you see

$ORIGIN/../lib:$ORIGIN/../../lib:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

When target architecture is x86_64 those folders don't exists in recipe-sysroot of a recipe that requires llvm-native.

The llvm_sysroot_preprocess_native function in current MR addresses that problem by
making RUNPATH target architecture dependent.

As to why RUNPATH includes both the original RUNPATH and the update target architecture
dependent directory name the llvm recipe requires the llvm-native llvm-config binary to
compile, but the build libs are stored in lib directory not lib64. Tried everything I could
think of change that not much can be done about that. When llvm-native gets included
in another recipe however libs are located at $ORIGIN/../lib64:$ORIGIN/../../lib64, at least
for TARGET ARCH x86_64.

As for the second problem llvm-config --libdir returns

/../../../../../../mesa/2_22.2.2-r0/recipe-sysroot/usr/lib

instead of

/../../../../../../mesa/2_22.2.2-r0/recipe-sysroot/usr/lib64

Which causes mesa configure to fail as ../../mesa/2_22.2.2-r0/recipe-sysroot/usr/lib doesn't exist.

According to https://github.com/llvm/llvm-project/blob/a11cd0d94ed3cabf0998a0289aead05da94c86eb/llvm/CMakeLists.txt#L399
and https://github.com/llvm/llvm-project/blob/a11cd0d94ed3cabf0998a0289aead05da94c86eb/llvm/CMakeLists.txt#L389

LLVM_LIBDIR_SUFFIX variable is used to set command. MR addresses that by setting the LLVM_LIBDIR_SUFFIX
variable. The reason I decided to use HOST_ARCH instead of TARGET_ARCH is because bitbake sets
HOST_ARCH = "${TARGET_ARCH}" in bitbake.conf, but I'll admit there's ignorance on my part in terms
of what I think that variable is set to and what class-native it used for.

:)

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