From: Khem Raj <raj.khem@gmail.com>
To: deepesh.varatharajan@windriver.com,
openembedded-core@lists.openembedded.org
Cc: Sundeep.Kokkonda@windriver.com
Subject: Re: [OE-core] [PATCH V3 1/2] rust: Use clang instead of rust-llvm
Date: Fri, 26 Sep 2025 09:50:02 -0700 [thread overview]
Message-ID: <09c1040b-742f-49a2-a36b-629104f1d1d2@gmail.com> (raw)
In-Reply-To: <20250926102411.3742996-1-Deepesh.Varatharajan@windriver.com>
On 9/26/25 3:24 AM, Varatharajan, Deepesh via lists.openembedded.org wrote:
> From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>
> Updated the Rust build to depend on Clang instead.
>
> *Summary of discussion with the rust upstream about using latest LLVM instead of Rust maintained LLVM fork.
> https://internals.rust-lang.org/t/can-we-use-proper-clang-instead-of-llvm-fork-what-rust-uses/23489
>
> *Upstream LLVM is generally compatible:
> - Rust does support building with upstream (vanilla) LLVM, especially the latest
> major release and the one or two preceding ones.
> https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#updating-llvm
>
> *Impact on Yocto Rust upgrades:
> - Rust upgrades shall always check for updates on rust forked llvm and backport
> the relevant patches to clang's llvm.
>
> *Regarding the rust forked llvm local patches:
> - There are no local patches on rust forked llvm other than the backported fixes
> from llvm master.
>
> *We now add these flags "-Clink-arg=-lz -Clink-arg=-lzstd" because of this following
> diff otherwise we will get errors during link time.
>
> Setup in rust-llvm
> -DLLVM_ENABLE_ZLIB=OFF \
> -DLLVM_ENABLE_ZSTD=OFF \
> -DLLVM_ENABLE_FFI=OFF \
>
> Setup in clang
> -DLLVM_ENABLE_FFI=ON \
> -DLLVM_ENABLE_ZSTD=ON \
>
> *When multilibs enabled:
>
> llvm-config expects static libraries to be located in the lib directory rather than
> lib64. However, since LLVM is built as a non-multilib component, the lib directory
> doesn't contain any library files. To accommodate this without breaking multilib
> behavior, we copy the required library files appropriately.
>
> Previously, when we depended on rust-llvm, this worked because we specified:
> -DCMAKE_INSTALL_PREFIX:PATH=${libdir}/llvm-rust
>
> With this setup, llvm-config was installed inside ${libdir}/llvm-rust, which included
> its own bin and lib directories. Thus, llvm-config located in bin would correctly find
> the libraries in the adjacent lib directory.
>
> Even when multilib was enabled or not, llvm-config would still look for libraries under
> lib in this structure, so everything functioned as expected.
>
> *Changes needs to be done when llvm splits from clang:
> In rust recipe:
> Update the dependency from:
> DEPENDS += "ninja-native clang" to DEPENDS += "ninja-native llvm"
>
> In llvm recipe:
> Apply the same changes that were made in the Clang recipe, as those
> configurations have now been moved to the LLVM recipe after the split.
>
> Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
> ---
> meta/recipes-devtools/clang/clang_git.bb | 4 ++--
> meta/recipes-devtools/clang/common-clang.inc | 6 +++---
> meta/recipes-devtools/rust/rust_1.90.0.bb | 18 ++++++++++++++----
> 3 files changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/meta/recipes-devtools/clang/clang_git.bb b/meta/recipes-devtools/clang/clang_git.bb
> index 53bca1c24f..3e117b308b 100644
> --- a/meta/recipes-devtools/clang/clang_git.bb
> +++ b/meta/recipes-devtools/clang/clang_git.bb
> @@ -83,7 +83,6 @@ OECMAKE_SOURCEPATH = "${S}/llvm"
> # https://github.com/llvm/llvm-project/blob/main/llvm/CMakeLists.txt
> LLVM_TARGETS_GPU ?= "${@bb.utils.contains_any('DISTRO_FEATURES', 'opencl opengl vulkan', 'AMDGPU;NVPTX;SPIRV', '', d)}"
> LLVM_TARGETS_TO_BUILD ?= "AArch64;ARM;BPF;Mips;PowerPC;RISCV;X86;LoongArch;${LLVM_TARGETS_GPU}"
> -LLVM_TARGETS_TO_BUILD:class-target ?= "${@get_clang_host_arch(bb, d)};BPF;${LLVM_TARGETS_GPU}"
>
> LLVM_EXPERIMENTAL_TARGETS_TO_BUILD ?= ""
>
> @@ -107,6 +106,7 @@ EXTRA_OECMAKE += "-DLLVM_ENABLE_ASSERTIONS=OFF \
> -DLLVM_ENABLE_PIC=ON \
> -DCLANG_DEFAULT_PIE_ON_LINUX=ON \
> -DLLVM_BINDINGS_LIST='' \
> + -DLLVM_INSTALL_UTILS=ON \
> -DLLVM_ENABLE_FFI=ON \
> -DLLVM_ENABLE_ZSTD=ON \
> -DFFI_INCLUDE_DIR=$(pkg-config --variable=includedir libffi) \
> @@ -137,7 +137,7 @@ EXTRA_OECMAKE:append:class-target = "\
> -DCMAKE_AR=${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}llvm-ar \
> -DCMAKE_NM=${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}llvm-nm \
> -DCMAKE_STRIP=${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}llvm-strip \
> - -DLLVM_TARGET_ARCH=${HOST_ARCH} \
> + -DLLVM_TARGET_ARCH=${@get_clang_target_arch(bb, d)} \
> -DLLVM_DEFAULT_TARGET_TRIPLE=${TARGET_SYS}${HF} \
> -DLLVM_HOST_TRIPLE=${TARGET_SYS}${HF} \
> -DLLVM_LIBDIR_SUFFIX=${LLVM_LIBDIR_SUFFIX} \
> diff --git a/meta/recipes-devtools/clang/common-clang.inc b/meta/recipes-devtools/clang/common-clang.inc
> index bf3a63914a..c22e3c1b19 100644
> --- a/meta/recipes-devtools/clang/common-clang.inc
> +++ b/meta/recipes-devtools/clang/common-clang.inc
> @@ -30,10 +30,10 @@ def get_clang_arch(bb, d, arch_var):
> elif re.match('aarch64$', a): return 'AArch64'
> elif re.match('aarch64_be$', a): return 'AArch64'
> elif re.match('mips(isa|)(32|64|)(r6|)(el|)$', a): return 'Mips'
> - elif re.match('riscv32$', a): return 'RISCV'
> - elif re.match('riscv64$', a): return 'RISCV'
> + elif re.match('riscv32$', a): return 'riscv32'
> + elif re.match('riscv64$', a): return 'riscv64'
> elif re.match('p(pc|owerpc)(|64)', a): return 'PowerPC'
> - elif re.match('loongarch64$', a): return 'LoongArch'
> + elif re.match('loongarch64$', a): return 'loongarch64'
> else:
> bb.fatal("Unhandled architecture %s" % arch_val)
> return ""
> diff --git a/meta/recipes-devtools/rust/rust_1.90.0.bb b/meta/recipes-devtools/rust/rust_1.90.0.bb
> index 5d804c7398..c2cb8f8829 100644
> --- a/meta/recipes-devtools/rust/rust_1.90.0.bb
> +++ b/meta/recipes-devtools/rust/rust_1.90.0.bb
> @@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=11a3899825f4376896e438c8c753f8dc"
> inherit rust
> inherit cargo_common
>
> -DEPENDS += "rust-llvm"
> +DEPENDS += "ninja-native clang"
> # native rust uses cargo/rustc from binary snapshots to bootstrap
> # but everything else should use our native builds
> DEPENDS:append:class-target = " cargo-native rust-native"
> @@ -28,8 +28,8 @@ PV .= "${@bb.utils.contains('RUST_CHANNEL', 'stable', '', '-${RUST_CHANNEL}', d)
>
> export FORCE_CRATE_HASH = "${BB_TASKHASH}"
>
> -RUST_ALTERNATE_EXE_PATH ?= "${STAGING_LIBDIR}/llvm-rust/bin/llvm-config"
> -RUST_ALTERNATE_EXE_PATH_NATIVE = "${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-config"
> +RUST_ALTERNATE_EXE_PATH ?= "${STAGING_BINDIR}/llvm-config"
> +RUST_ALTERNATE_EXE_PATH_NATIVE = "${STAGING_BINDIR_NATIVE}/llvm-config"
>
> # We don't want to use bitbakes vendoring because the rust sources do their
> # own vendoring.
> @@ -188,6 +188,16 @@ python do_configure() {
> bb.build.exec_func("setup_cargo_environment", d)
> }
>
> +#llvm-config expecting static libraries in 'lib' instead of 'lib64'.
> +#Since LLVM is built as a non-multilib component, the 'lib' directory
> +#doesn't have any library files when multilibs enabled. So, copying
> +#library files without impacting multilib behavior.
> +do_compile:append:class-target() {
> +if [ -d ${STAGING_DIR_TARGET}/usr/lib64 ]; then
> + cp ${STAGING_DIR_TARGET}/usr/lib64/libLLVM*.a ${STAGING_DIR_TARGET}/usr/lib/.
> +fi
> +}
llvm-config can deduce paths to be self-relative, You might try to
create a copy of native llvm-config in STAGING_LIBDIR or STAGING_BINDIR
and that might help
> +
> rust_runx () {
> echo "COMPILE ${PN}" "$@"
>
> @@ -199,7 +209,7 @@ rust_runx () {
> unset CXXFLAGS
> unset CPPFLAGS
>
> - export RUSTFLAGS="${RUST_DEBUG_REMAP}"
> + export RUSTFLAGS="${RUST_DEBUG_REMAP} -Clink-arg=-lz -Clink-arg=-lzstd"
>
> # Copy the natively built llvm-config into the target so we can run it. Horrible,
> # but works!
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#224075): https://lists.openembedded.org/g/openembedded-core/message/224075
> Mute This Topic: https://lists.openembedded.org/mt/115446166/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
next prev parent reply other threads:[~2025-09-26 16:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 10:24 [PATCH V3 1/2] rust: Use clang instead of rust-llvm Deepesh.Varatharajan
2025-09-26 10:24 ` [PATCH V3 2/2] rust: Drop rust-llvm Deepesh.Varatharajan
2025-09-26 16:50 ` Khem Raj [this message]
2025-09-29 10:17 ` [OE-core] [PATCH V3 1/2] rust: Use clang instead of rust-llvm Deepesh Varatharajan
2025-09-26 17:30 ` Khem Raj
2025-09-29 8:29 ` Deepesh Varatharajan
2025-10-01 19:29 ` Khem Raj
2025-10-07 11:10 ` Deepesh Varatharajan
2025-10-07 20:17 ` Khem Raj
2025-10-08 12:49 ` Deepesh Varatharajan
2025-10-08 12:54 ` Richard Purdie
2025-10-10 9:27 ` Deepesh Varatharajan
2025-10-10 9:36 ` Richard Purdie
2025-09-29 8:11 ` Mathieu Dubois-Briand
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=09c1040b-742f-49a2-a36b-629104f1d1d2@gmail.com \
--to=raj.khem@gmail.com \
--cc=Sundeep.Kokkonda@windriver.com \
--cc=deepesh.varatharajan@windriver.com \
--cc=openembedded-core@lists.openembedded.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