You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Executables that are cross-built using clang have the dynamic linker set to /lib64/ld-linux-x86-64.so.2 while it is actually found at /usr/lib/ld-linux-x86-64.so.2.
Build and and target are both x86_64. MACHINE is derived from poky's genericx86-64.
This is based on meta-clang commit 5170ec9 / branch nanbield (clang-17.0.4), poky tag yocto-4.3.1. meta-openembedded branch nanbield as of 19-DEC-2023.
$ ls $OECORE_TARGET_SYSROOT
boot etc lib run usr var
$ ls $OECORE_TARGET_SYSROOT/lib
modules
ls $OECORE_TARGET_SYSROOT/usr/lib/ld*
[...]/usr/lib/ld-linux-x86-64.so.2
Target host:
$ /tmp/go
-bash: /tmp/go: cannot execute: required file not found
Expected behavior
Building an executable file using clang sets the dynamic linker to /usr/lib/ld-linux-x86-64.so.2
Additional context
Seems like the patches for Linux::getDynamicLinker() trip over the case the linker is neither found in /usr/lib64 nor in /lib and then defaults to /lib64/ld-linux-x86-64.so.2.
Affected patches:
0006-clang-driver-Check-sysroot-for-ldso-path.patch
0017-clang-driver-Add-dyld-prefix-when-checking-sysroot-f.patch
Previously that system was based on kirkstone and for the corresponding SDK target sysroot the linker (and a subset of shared libs) is still located in /usr and so it went fine. For nanbield all is put into /usr/lib.
(Building natively on target would probably work fine since a symlink from /usr to /usr/lib exists.)
While the latest state of master was not tried the set of relevant patches appear to be mostly identical.
There is a patch available for the mentioned ones, yet it covers x86_64 only. I'm willing to provide a complete one in case all of this makes sense :-)
Describe the bug
Executables that are cross-built using clang have the dynamic linker set to /lib64/ld-linux-x86-64.so.2 while it is actually found at /usr/lib/ld-linux-x86-64.so.2.
Build and and target are both x86_64. MACHINE is derived from poky's genericx86-64.
This is based on meta-clang commit 5170ec9 / branch nanbield (clang-17.0.4), poky tag yocto-4.3.1. meta-openembedded branch nanbield as of 19-DEC-2023.
To Reproduce
Steps to reproduce the behavior:
Build host:
$ bitbake meta-toolchain
$ "install SDK"
$ "source SDK environment file"
$ $CLANGCC -o ~/tmp/go ~/tmp/main.c
$ $READELF -p .interp ~/tmp/go
String dump of section '.interp':
[ 0] /lib64/ld-linux-x86-64.so.2
$ ls $OECORE_TARGET_SYSROOT
boot etc lib run usr var
$ ls $OECORE_TARGET_SYSROOT/lib
modules
ls $OECORE_TARGET_SYSROOT/usr/lib/ld*
[...]/usr/lib/ld-linux-x86-64.so.2
Target host:
$ /tmp/go
-bash: /tmp/go: cannot execute: required file not found
Expected behavior
Building an executable file using clang sets the dynamic linker to /usr/lib/ld-linux-x86-64.so.2
Additional context
Seems like the patches for Linux::getDynamicLinker() trip over the case the linker is neither found in /usr/lib64 nor in /lib and then defaults to /lib64/ld-linux-x86-64.so.2.
Affected patches:
0006-clang-driver-Check-sysroot-for-ldso-path.patch
0017-clang-driver-Add-dyld-prefix-when-checking-sysroot-f.patch
Previously that system was based on kirkstone and for the corresponding SDK target sysroot the linker (and a subset of shared libs) is still located in /usr and so it went fine. For nanbield all is put into /usr/lib.
(Building natively on target would probably work fine since a symlink from /usr to /usr/lib exists.)
While the latest state of master was not tried the set of relevant patches appear to be mostly identical.
There is a patch available for the mentioned ones, yet it covers x86_64 only. I'm willing to provide a complete one in case all of this makes sense :-)
0001-clang-set-x86_64-dyld-path-according-to-yocto-4.3.1.patch.txt
The text was updated successfully, but these errors were encountered: