Wait. When you invoke native llvm-config it must be able to locate *native* libraries that it is linked with. And so rpath must be set to where they are, which is $ORIGIN/../lib. Why does it need to be changed to something defined differently for some target?
Then you seem to say that 'llvm-config --libdir' returns something incorrect, but is that an actual problem? Where in the mesa build is it used, and how can the issue be observed? We regularly build mesa with llvm, and it does not fail. Alex On Sun, 13 Nov 2022 at 20:17, Vincent Davis Jr <vi...@underview.tech> wrote: > > 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 (#173210): https://lists.openembedded.org/g/openembedded-core/message/173210 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] -=-=-=-=-=-=-=-=-=-=-=-
