On 12-06-2026 14:09, Richard Purdie wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Thu, 2026-06-11 at 20:46 -0700, [email protected] wrote:
From: Deepesh Varatharajan <[email protected]>
Replace PATH-based llvm-config discovery with explicit sysroot-native
resolution and simplify the target llvm-config wrapper to act as a pure
pass-through while preserving Yocto alternate path handling.
The previous implementation relied on:
* `which -a llvm-config | sed -n 2p`
which is unreliable in cross-build environments because it only
searches executables present in $PATH. Native sysroot tools
(e.g. recipe-sysroot-native llvm-config) are not guaranteed to be
exposed via PATH, so they may not be discovered at all.
We always configure PATH to contain the cross scripts and native
sysroot. Is there something which is reconfiguring PATH to skip the
native sysroot?
After running bitbake rust -c devshell, I checked echo $PATH and seen native
sysroot path present there.
In this case, since we already know the exact location from which
llvm-config should
be used, would it make sense to reference that path directly instead of
recursively
searching for llvm-config from the current directory?
* `echo $base_libdir | sed -n '/lib64/p'`
which depends on a BitBake variable that may be empty or unset
in certain build contexts, leading to incorrect libdir selection.
Update the wrapper to:
* Use an @LLVM_CONFIG_PATH@ placeholder that is replaced during the
build with the appropriate native llvm-config path.
* Detect libdir using filesystem inspection rather than variable
parsing.
* Preserve `YOCTO_ALTERNATE_EXE_PATH` and
`YOCTO_ALTERNATE_LIBDIR` handling.
* Delegate all arguments directly to the native llvm-config.
Update rust and mesa recipes to replace the placeholder with the native
llvm-config path during target and nativesdk builds.
Also remove the native llvm-config copy logic and lib/lib64 symlink
workarounds, relying instead on explicit native tool resolution.
Signed-off-by: Deepesh Varatharajan <[email protected]>
---
...unwind.pc.in-and-llvm-config-scripts.patch | 52 +++----------------
meta/recipes-devtools/rust/rust_1.96.0.bb | 52 ++++++-------------
meta/recipes-graphics/mesa/mesa.inc | 16 ++++++
3 files changed, 39 insertions(+), 81 deletions(-)
diff --git
a/meta/recipes-devtools/clang/clang/0026-llvm-Add-libunwind.pc.in-and-llvm-config-scripts.patch
b/meta/recipes-devtools/clang/clang/0026-llvm-Add-libunwind.pc.in-and-llvm-config-scripts.patch
index eeb802732b..72ffdc6c1f 100644
---
a/meta/recipes-devtools/clang/clang/0026-llvm-Add-libunwind.pc.in-and-llvm-config-scripts.patch
+++
b/meta/recipes-devtools/clang/clang/0026-llvm-Add-libunwind.pc.in-and-llvm-config-scripts.patch
@@ -8,6 +8,7 @@ These are added by OE project
Upstream-Status: Inappropriate [ OE-Specific ]
Signed-off-by: Khem Raj <[email protected]>
+Signed-off-by: Deepesh Varatharajan <[email protected]>
---
libunwind/libunwind.pc.in | 9 ++++++
llvm/tools/llvm-config/llvm-config | 52 ++++++++++++++++++++++++++++++
@@ -35,56 +36,19 @@ new file mode 100644
index 000000000000..6a0dd54b8eab
--- /dev/null
+++ b/llvm/tools/llvm-config/llvm-config
-@@ -0,0 +1,52 @@
+@@ -0,0 +1,15 @@
+#!/bin/bash
+#
-+# Wrapper script for llvm-config. Supplies the right environment variables
-+# for the target and delegates to the native llvm-config for anything else.
This
-+# is needed because arguments like --ldflags, --cxxflags, etc. are set by the
-+# native compile rather than the target compile.
++# The llvm-config wrapper will act as a pure pass-through to the native
llvm-config
++# while preserving Yocto-specific environment variables used for alternate
executable
++# and library path resolution.
+#
+SCRIPT_DIR="$(dirname "$(readlink -f "$0")")"
-+NEXT_LLVM_CONFIG="$(which -a llvm-config | sed -n 2p)"
++NEXT_LLVM_CONFIG="@LLVM_CONFIG_PATH@"
As I understand it, this is always being configured to point at the
llvm-config in the native sysroot?
yes
I think this script is only ever installed into STAGING_BINDIR_CROSS?
yes
If that is the case, could we just set this to a relative path to
SCRIPT_DIR, which would then always point at the right places without
needing to be adjusted each time?
This script is used in both target and nativesdk builds, and the
directory layout differs between them.
For example:
target : "../recipe-sysroot/usr/bin/crossscripts"
nativesdk :
"../recipe-sysroot/usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-oesdk-linux/usr/bin/crossscripts"
Because the relative location of native llvm-config with respect to
SCRIPT_DIR is not the same in these two environments,
a single path relative from SCRIPT_DIR would not resolve correctly in
both cases. Therefore, the path cannot be expressed
as one fixed relative path and still work for both target and nativesdk
builds.
+export YOCTO_ALTERNATE_EXE_PATH="${YOCTO_ALTERNATE_EXE_PATH:="$(readlink -f
"$SCRIPT_DIR/../llvm-config")"}"
-+if [ -n "$( echo $base_libdir | sed -n '/lib64/p')" ]; then
++if [ -d "$(readlink -f "$SCRIPT_DIR/../../lib64")" ]; then
+ export YOCTO_ALTERNATE_LIBDIR="${YOCTO_ALTERNATE_LIBDIR:="/lib64"}"
+else
+ export YOCTO_ALTERNATE_LIBDIR="${YOCTO_ALTERNATE_LIBDIR:="/lib"}"
+fi
-+if [[ $# == 0 ]]; then
-+ exec "$NEXT_LLVM_CONFIG"
-+fi
-+
-+remain=""
-+output=""
-+for arg in "$@"; do
-+ case "$arg" in
-+ --cppflags)
-+ output="${output} ${CPPFLAGS}"
-+ ;;
-+ --cflags)
-+ output="${output} ${CFLAGS}"
-+ ;;
Can you remind me, how does the native llvm-config provide the target
cflags? Is that triggered by setting the YOCTO_ALTERNATE_LIBDIR above?
Yes.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#238802):
https://lists.openembedded.org/g/openembedded-core/message/238802
Mute This Topic: https://lists.openembedded.org/mt/119769053/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
