Openembedded Core Discussions
 help / color / mirror / Atom feed
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


      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