To be specific:
alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ldd
tmp/work/core2-64-poky-linux/mesa/2_22.2.2-r0/recipe-sysroot-native/usr/bin/llvm-config
linux-vdso.so.1 (0x00007fffe9964000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f415335d000)
libtinfo.so.5 =>
/srv/storage/alex/yocto/build-64-alt/tmp/work/core2-64-poky-linux/mesa/2_22.2.2-r0/recipe-sysroot-native/usr/bin/../lib/libtinfo.so.5
(0x00007f415332e000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4153161000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f415301d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4153001000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4152e2c000)
/srv/storage/alex/yocto/build-64-alt/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
=> /lib64/ld-linux-x86-64.so.2 (0x00007f41533c3000)
See how it's able to link with libtinfo in sysroot-native? That's
precisely because of rpath telling it to.
Alex
On Sun, 13 Nov 2022 at 22:54, Alexander Kanavin <alex.kana...@gmail.com> wrote:
>
> 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 (#173211):
https://lists.openembedded.org/g/openembedded-core/message/173211
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]
-=-=-=-=-=-=-=-=-=-=-=-
