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. :)
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#173209): https://lists.openembedded.org/g/openembedded-core/message/173209 Mute This Topic: https://lists.openembedded.org/mt/94995332/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
