From: Deepesh Varatharajan <deepesh.varatharajan@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
openembedded-core@lists.openembedded.org
Cc: Sundeep.Kokkonda@windriver.com
Subject: Re: [PATCH v3] llvm/mesa/rust: simplify llvm-config handling
Date: Mon, 15 Jun 2026 09:15:53 +0530 [thread overview]
Message-ID: <61bf8000-46de-4c76-b76f-9701f0fae4e8@windriver.com> (raw)
In-Reply-To: <81d9b55d8be3f08a199c0ed82cc5a68a3e083cdd.camel@linuxfoundation.org>
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, Deepesh.Varatharajan@windriver.com wrote:
>> From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>>
>> 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 <Deepesh.Varatharajan@windriver.com>
>> ---
>> ...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 <raj.khem@gmail.com>
>> +Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>> ---
>> 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
prev parent reply other threads:[~2026-06-15 3:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 3:46 [PATCH v3] llvm/mesa/rust: simplify llvm-config handling Deepesh.Varatharajan
2026-06-12 8:39 ` Richard Purdie
2026-06-15 3:45 ` Deepesh Varatharajan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=61bf8000-46de-4c76-b76f-9701f0fae4e8@windriver.com \
--to=deepesh.varatharajan@windriver.com \
--cc=Sundeep.Kokkonda@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox