* [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB
@ 2025-10-15 9:59 Deepesh.Varatharajan
2025-10-15 9:59 ` [PATCH V5 2/3] rust: Use llvm instead of rust-llvm Deepesh.Varatharajan
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Deepesh.Varatharajan @ 2025-10-15 9:59 UTC (permalink / raw)
To: openembedded-core; +Cc: Sundeep.Kokkonda, Deepesh.Varatharajan
From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Rightnow rust depends on llvm instead of rust-llvm
Setup in rust-llvm
CFLAGS:remove = "-g"
CXXFLAGS:remove = "-g"
Setup in llvm
DEBUG_LEVELFLAG = "-g1"
As a result, the stage1 compiler crate binaries include debug symbols,
increasing their size. These binaries are used to run tests inside QEMU.
To accommodate this, increase the QEMU RAM allocation to 1024 MB.
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
---
meta/lib/oeqa/selftest/cases/rust.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/rust.py b/meta/lib/oeqa/selftest/cases/rust.py
index 95859a9eef..06acf53e9a 100644
--- a/meta/lib/oeqa/selftest/cases/rust.py
+++ b/meta/lib/oeqa/selftest/cases/rust.py
@@ -102,8 +102,9 @@ class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
testargs = exclude_fail_tests + " --no-doc --no-fail-fast --bless"
# wrap the execution with a qemu instance.
- # Tests are run with 512 tasks in parallel to execute all tests very quickly
- with runqemu("core-image-minimal", runqemuparams = "nographic", qemuparams = "-m 512") as qemu:
+ # Set QEMU RAM to 1024MB to support running unit tests for the compiler crate, including larger
+ # test cases and parallel execution in the test environment.
+ with runqemu("core-image-minimal", runqemuparams = "nographic", qemuparams = "-m 1024") as qemu:
# Copy remote-test-server to image through scp
host_sys = get_bb_var("RUST_BUILD_SYS", "rust")
ssh = SSHControl(ip=qemu.ip, logfile=qemu.sshlog, user="root")
--
2.49.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH V5 2/3] rust: Use llvm instead of rust-llvm
2025-10-15 9:59 [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB Deepesh.Varatharajan
@ 2025-10-15 9:59 ` Deepesh.Varatharajan
2025-10-17 6:01 ` [OE-core] " Khem Raj
2025-10-20 11:23 ` Ross Burton
2025-10-15 9:59 ` [PATCH V5 3/3] rust: Drop rust-llvm Deepesh.Varatharajan
2025-10-16 6:31 ` [OE-core] [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB Richard Purdie
2 siblings, 2 replies; 12+ messages in thread
From: Deepesh.Varatharajan @ 2025-10-15 9:59 UTC (permalink / raw)
To: openembedded-core; +Cc: Sundeep.Kokkonda, Deepesh.Varatharajan
From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Updated the Rust build to depend on llvm 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 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 are copying the natively built `llvm-config` binary into the target sysroot and running
it. However, this `llvm-config` has compile time dependencies on various other arch's LLVM
libraries because native-llvm is built for all oe-core supported targets.
Attempting to work around this by symlinking the missing libraries from the native sysroot
into the target sysroot leads to mixed architectures in the final `.rlib`. Specifically,
the object files extracted from those symlinked libraries within `librustc_llvm-<hash>.rlib`
are built for the host, while others are correctly built for the target This results in linker
failures due to file format not recognized.
To resolve this, we now build llvm-target also for all oe-core supported architectures in
addition to the native-llvm build. This ensures that `llvm-config` and all associated
libraries are built for the correct target, eliminating cross-architecture contamination
and linker issues.
*We are enabling -DLLVM_INSTALL_UTILS=ON to ensure essential LLVM utilities like FileCheck
are available, as they are required by the Rust build.
Without this, the build fails with an error as below:
| thread 'main' panicked at src/bootstrap/src/core/sanity.rs:315:21:
| FileCheck executable "poky/build/tmp/work/x86_64-linux/rust-native/1.90.0/recipe-sysroot
-native/usr/bin/FileCheck" does not exist
*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 llvm
-DLLVM_ENABLE_FFI=ON \
*When multilibs enabled:
llvm-config expects static libraries to be located in the lib directory rather than
lib64. However, since we are copying the natively built llvm-config to target sysroot
and running it and llvm-config doesn't know anything about lib64 existence. To accommodate
this without breaking multilib behavior, we are creating a symlink from 'lib' to 'lib64'
directory.
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.
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
---
meta/recipes-devtools/clang/llvm_git.bb | 2 +-
meta/recipes-devtools/rust/rust_1.90.0.bb | 39 ++++++++++++++++++++---
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-devtools/clang/llvm_git.bb b/meta/recipes-devtools/clang/llvm_git.bb
index d2b060ff88..2f47af8d7a 100644
--- a/meta/recipes-devtools/clang/llvm_git.bb
+++ b/meta/recipes-devtools/clang/llvm_git.bb
@@ -27,7 +27,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 ?= ""
@@ -37,6 +36,7 @@ HF[vardepvalue] = "${HF}"
EXTRA_OECMAKE += "-DCMAKE_BUILD_TYPE=MinSizeRel \
-DLLVM_ENABLE_BINDINGS=OFF \
+ -DLLVM_INSTALL_UTILS=ON \
-DLLVM_ENABLE_FFI=ON \
-DLLVM_ENABLE_RTTI=ON \
-DLLVM_TARGETS_TO_BUILD='${LLVM_TARGETS_TO_BUILD}' \
diff --git a/meta/recipes-devtools/rust/rust_1.90.0.bb b/meta/recipes-devtools/rust/rust_1.90.0.bb
index 5d804c7398..0319d73b93 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 += "llvm"
# 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,37 @@ python do_configure() {
bb.build.exec_func("setup_cargo_environment", d)
}
+# llvm-config expects static libraries to be in the 'lib' directory rather than 'lib64' when
+# multilibs enabled. Since we are copying the natively built llvm-config into the target sysroot
+# and executing it there, it will default to searching in 'lib', as it is unaware of the 'lib64'
+# directory. To ensure llvm-config can locate the necessary libraries, create a symlink from 'lib'
+do_compile:append:class-target() {
+ # Ensure llvm-config can find static libraries in multilib setup
+ lib64_dir="${STAGING_DIR_TARGET}/usr/lib64"
+ lib_dir="${STAGING_DIR_TARGET}/usr/lib"
+
+ if [ -d "$lib64_dir" ]; then
+ # If lib does not exist, symlink it to lib64
+ if [ ! -e "$lib_dir" ]; then
+ ln -s lib64 "$lib_dir"
+ fi
+
+ # Only do per-file symlinking if lib is a real directory (not symlink)
+ if [ -d "$lib_dir" ] && [ ! -L "$lib_dir" ]; then
+ for lib64_file in "${lib64_dir}"/libLLVM*.a; do
+ if [ -e "$lib64_file" ]; then
+ lib_name=$(basename "${lib64_file}")
+ target_link="${lib_dir}/${lib_name}"
+
+ if [ ! -e "${target_link}" ]; then
+ ln -s "../lib64/${lib_name}" "${target_link}"
+ fi
+ fi
+ done
+ fi
+ fi
+}
+
rust_runx () {
echo "COMPILE ${PN}" "$@"
@@ -199,7 +230,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!
--
2.49.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH V5 3/3] rust: Drop rust-llvm
2025-10-15 9:59 [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB Deepesh.Varatharajan
2025-10-15 9:59 ` [PATCH V5 2/3] rust: Use llvm instead of rust-llvm Deepesh.Varatharajan
@ 2025-10-15 9:59 ` Deepesh.Varatharajan
2025-10-16 6:31 ` [OE-core] [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB Richard Purdie
2 siblings, 0 replies; 12+ messages in thread
From: Deepesh.Varatharajan @ 2025-10-15 9:59 UTC (permalink / raw)
To: openembedded-core; +Cc: Sundeep.Kokkonda, Deepesh.Varatharajan
From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Dropping rust-llvm because now rust depends on llvm.
0001-AsmMatcherEmitter-sort-ClassInfo-lists-by-name-as-we.patch
0002-llvm-allow-env-override-of-exe-path.patch
(We have the above two patches in llvm)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
---
meta/conf/distro/include/maintainers.inc | 1 -
.../distro/include/rust_security_flags.inc | 1 -
meta/conf/distro/include/tcmode-default.inc | 2 -
...r-sort-ClassInfo-lists-by-name-as-we.patch | 31 ------
...-llvm-allow-env-override-of-exe-path.patch | 33 -------
.../recipes-devtools/rust/rust-llvm_1.90.0.bb | 98 -------------------
6 files changed, 166 deletions(-)
delete mode 100644 meta/recipes-devtools/rust/rust-llvm/0001-AsmMatcherEmitter-sort-ClassInfo-lists-by-name-as-we.patch
delete mode 100644 meta/recipes-devtools/rust/rust-llvm/0002-llvm-allow-env-override-of-exe-path.patch
delete mode 100644 meta/recipes-devtools/rust/rust-llvm_1.90.0.bb
diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc
index deac453365..444c7f6521 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -774,7 +774,6 @@ RECIPE_MAINTAINER:pn-ruby = "Ross Burton <ross.burton@arm.com>"
RECIPE_MAINTAINER:pn-run-postinsts = "Ross Burton <ross.burton@arm.com>"
RECIPE_MAINTAINER:pn-rust = "Randy MacLeod <Randy.MacLeod@windriver.com>"
RECIPE_MAINTAINER:pn-rust-cross-canadian-${TRANSLATED_TARGET_ARCH} = "Randy MacLeod <Randy.MacLeod@windriver.com>"
-RECIPE_MAINTAINER:pn-rust-llvm = "Randy MacLeod <Randy.MacLeod@windriver.com>"
RECIPE_MAINTAINER:pn-rxvt-unicode = "Unassigned <unassigned@yoctoproject.org>"
RECIPE_MAINTAINER:pn-sassc = "Simone Weiß <simone.p.weiss@posteo.com>"
RECIPE_MAINTAINER:pn-sato-screenshot = "Ross Burton <ross.burton@arm.com>"
diff --git a/meta/conf/distro/include/rust_security_flags.inc b/meta/conf/distro/include/rust_security_flags.inc
index 590bef17a0..f77c851197 100644
--- a/meta/conf/distro/include/rust_security_flags.inc
+++ b/meta/conf/distro/include/rust_security_flags.inc
@@ -2,6 +2,5 @@
SECURITY_CFLAGS:pn-rust-native = "${SECURITY_NO_PIE_CFLAGS}"
SECURITY_CFLAGS:pn-rust-cross-${TARGET_ARCH} = "${SECURITY_NO_PIE_CFLAGS}"
SECURITY_CFLAGS:pn-rust = "${SECURITY_NO_PIE_CFLAGS}"
-SECURITY_CFLAGS:pn-rust-llvm = "${SECURITY_NO_PIE_CFLAGS}"
SECURITY_LDFLAGS:pn-rust-cross-arm = " -lssp_nonshared -lssp"
diff --git a/meta/conf/distro/include/tcmode-default.inc b/meta/conf/distro/include/tcmode-default.inc
index 133608a6e7..ff10f14a6b 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -43,7 +43,5 @@ PREFERRED_VERSION_cargo-native ?= "${RUSTVERSION}"
PREFERRED_VERSION_libstd-rs ?= "${RUSTVERSION}"
PREFERRED_VERSION_rust ?= "${RUSTVERSION}"
PREFERRED_VERSION_rust-cross-${TARGET_ARCH} ?= "${RUSTVERSION}"
-PREFERRED_VERSION_rust-llvm ?= "${RUSTVERSION}"
-PREFERRED_VERSION_rust-llvm-native ?= "${RUSTVERSION}"
PREFERRED_VERSION_rust-native ?= "${RUSTVERSION}"
diff --git a/meta/recipes-devtools/rust/rust-llvm/0001-AsmMatcherEmitter-sort-ClassInfo-lists-by-name-as-we.patch b/meta/recipes-devtools/rust/rust-llvm/0001-AsmMatcherEmitter-sort-ClassInfo-lists-by-name-as-we.patch
deleted file mode 100644
index 48af6fc283..0000000000
--- a/meta/recipes-devtools/rust/rust-llvm/0001-AsmMatcherEmitter-sort-ClassInfo-lists-by-name-as-we.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From 86940d87026432683fb6741cd8a34d3b9b18e40d Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin <alex.kanavin@gmail.com>
-Date: Fri, 27 Nov 2020 10:11:08 +0000
-Subject: [PATCH] AsmMatcherEmitter: sort ClassInfo lists by name as well
-
-Otherwise, there are instances which are identical in
-every other field and therefore sort non-reproducibly
-(which breaks binary and source reproducibiliy).
-
-Upstream-Status: Submitted [https://reviews.llvm.org/D97477]
-Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
----
- llvm/utils/TableGen/AsmMatcherEmitter.cpp | 5 ++++-
- 1 file changed, 4 insertions(+), 1 deletion(-)
-
-diff --git a/llvm/utils/TableGen/AsmMatcherEmitter.cpp b/llvm/utils/TableGen/AsmMatcherEmitter.cpp
-index ccf0959389b..1f801e83b7d 100644
---- a/llvm/utils/TableGen/AsmMatcherEmitter.cpp
-+++ b/llvm/utils/TableGen/AsmMatcherEmitter.cpp
-@@ -359,7 +359,10 @@ public:
- // name of a class shouldn't be significant. However, some of the backends
- // accidentally rely on this behaviour, so it will have to stay like this
- // until they are fixed.
-- return ValueName < RHS.ValueName;
-+ if (ValueName != RHS.ValueName)
-+ return ValueName < RHS.ValueName;
-+ // All else being equal, we should sort by name, for source and binary reproducibility
-+ return Name < RHS.Name;
- }
- };
-
diff --git a/meta/recipes-devtools/rust/rust-llvm/0002-llvm-allow-env-override-of-exe-path.patch b/meta/recipes-devtools/rust/rust-llvm/0002-llvm-allow-env-override-of-exe-path.patch
deleted file mode 100644
index 9be26677a9..0000000000
--- a/meta/recipes-devtools/rust/rust-llvm/0002-llvm-allow-env-override-of-exe-path.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From 7111770e8290082530d920e120995bf81431b0aa Mon Sep 17 00:00:00 2001
-From: Martin Kelly <mkelly@xevo.com>
-Date: Fri, 19 May 2017 00:22:57 -0700
-Subject: [PATCH 12/18] llvm: allow env override of exe path
-
-When using a native llvm-config from inside a sysroot, we need llvm-config to
-return the libraries, include directories, etc. from inside the sysroot rather
-than from the native sysroot. Thus provide an env override for calling
-llvm-config from a target sysroot.
-
-Upstream-Status: Inappropriate [oe-core specific]
-Signed-off-by: Martin Kelly <mkelly@xevo.com>
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
----
- llvm/tools/llvm-config/llvm-config.cpp | 7 +++++++
- 1 file changed, 7 insertions(+)
-
---- a/llvm/tools/llvm-config/llvm-config.cpp
-+++ b/llvm/tools/llvm-config/llvm-config.cpp
-@@ -226,6 +226,13 @@ Typical components:\n\
-
- /// Compute the path to the main executable.
- std::string GetExecutablePath(const char *Argv0) {
-+ // Hack for Yocto: we need to override the root path when we are using
-+ // llvm-config from within a target sysroot.
-+ const char *Sysroot = std::getenv("YOCTO_ALTERNATE_EXE_PATH");
-+ if (Sysroot != nullptr) {
-+ return Sysroot;
-+ }
-+
- // This just needs to be some symbol in the binary; C++ doesn't
- // allow taking the address of ::main however.
- void *P = (void *)(intptr_t)GetExecutablePath;
diff --git a/meta/recipes-devtools/rust/rust-llvm_1.90.0.bb b/meta/recipes-devtools/rust/rust-llvm_1.90.0.bb
deleted file mode 100644
index 42d4031da1..0000000000
--- a/meta/recipes-devtools/rust/rust-llvm_1.90.0.bb
+++ /dev/null
@@ -1,98 +0,0 @@
-SUMMARY = "LLVM compiler framework (packaged with rust)"
-LICENSE ?= "Apache-2.0-with-LLVM-exception"
-HOMEPAGE = "http://www.rust-lang.org"
-
-# check src/llvm-project/llvm/CMakeLists.txt for llvm version in use
-#
-LLVM_RELEASE = "20.1.8"
-
-require rust-source.inc
-
-SRC_URI += "file://0002-llvm-allow-env-override-of-exe-path.patch;striplevel=2 \
- file://0001-AsmMatcherEmitter-sort-ClassInfo-lists-by-name-as-we.patch;striplevel=2 \
- "
-
-S = "${RUSTSRC}/src/llvm-project/llvm"
-
-LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=8a15a0759ef07f2682d2ba4b893c9afe"
-
-inherit cmake
-
-DEPENDS += "ninja-native rust-llvm-native"
-
-ARM_INSTRUCTION_SET:armv5 = "arm"
-ARM_INSTRUCTION_SET:armv4t = "arm"
-
-# rustc_llvm with debug info is not recognized as a valid crate that's
-# generated by rust-llvm-native.
-CFLAGS:remove = "-g"
-CXXFLAGS:remove = "-g"
-
-LLVM_DIR = "llvm${LLVM_RELEASE}"
-
-RUST_LLVM_TARGETS ?= "ARM;AArch64;Mips;PowerPC;RISCV;X86"
-
-EXTRA_OECMAKE = " \
- -DCMAKE_BUILD_TYPE=Release \
- -DLLVM_TARGETS_TO_BUILD='${RUST_LLVM_TARGETS}' \
- -DLLVM_BUILD_DOCS=OFF \
- -DLLVM_ENABLE_TERMINFO=OFF \
- -DLLVM_ENABLE_ZLIB=OFF \
- -DLLVM_ENABLE_ZSTD=OFF \
- -DLLVM_ENABLE_LIBXML2=OFF \
- -DLLVM_ENABLE_FFI=OFF \
- -DLLVM_ENABLE_LIBEDIT=OFF \
- -DLLVM_INSTALL_UTILS=ON \
- -DLLVM_BUILD_EXAMPLES=OFF \
- -DLLVM_BUILD_LLVM_DYLIB=ON \
- -DLLVM_LINK_LLVM_DYLIB=ON \
- -DLLVM_INCLUDE_EXAMPLES=OFF \
- -DLLVM_BUILD_TESTS=OFF \
- -DLLVM_INCLUDE_TESTS=OFF \
- -DLLVM_INCLUDE_BENCHMARKS=OFF \
- -DLLVM_TARGET_ARCH=${TARGET_ARCH} \
- -DCMAKE_INSTALL_PREFIX:PATH=${libdir}/llvm-rust \
-"
-
-# Forcibly disable the detection of these packages as otherwise
-# it will look at the host Python install
-EXTRA_OECMAKE += "\
- -DPY_PYGMENTS_FOUND=OFF \
- -DPY_PYGMENTS_LEXERS_C_CPP_FOUND=OFF \
- -DPY_YAML_FOUND=OFF \
-"
-
-EXTRA_OECMAKE:append:class-target = "\
- -DLLVM_BUILD_TOOLS=OFF \
- -DLLVM_TABLEGEN=${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-tblgen \
- -DLLVM_CONFIG_PATH=${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-config \
-"
-
-EXTRA_OECMAKE:append:class-nativesdk = "\
- -DLLVM_BUILD_TOOLS=OFF \
- -DLLVM_TABLEGEN=${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-tblgen \
- -DLLVM_CONFIG_PATH=${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-config \
-"
-
-# The debug symbols are huge here (>2GB) so suppress them since they
-# provide almost no value. If you really need them then override this
-INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
-
-export YOCTO_ALTERNATE_EXE_PATH = "${STAGING_LIBDIR}/llvm-rust/bin/llvm-config"
-
-do_install:append () {
- # we don't need any of this stuff to build Rust
- rm -rf "${D}/usr/lib/cmake"
-}
-
-PACKAGES =+ "${PN}-bugpointpasses ${PN}-llvmhello ${PN}-liblto"
-
-# Add the extra locations to avoid the complaints about unpackaged files
-FILES:${PN}-bugpointpasses = "${libdir}/llvm-rust/lib/BugpointPasses.so"
-FILES:${PN}-llvmhello = "${libdir}/llvm-rust/lib/LLVMHello.so"
-FILES:${PN}-liblto = "${libdir}/llvm-rust/lib/libLTO.so.*"
-FILES:${PN}-staticdev =+ "${libdir}/llvm-rust/*/*.a"
-FILES:${PN} += "${libdir}/libLLVM*.so.* ${libdir}/llvm-rust/lib/*.so.* ${libdir}/llvm-rust/bin"
-FILES:${PN}-dev += "${datadir}/llvm ${libdir}/llvm-rust/lib/*.so ${libdir}/llvm-rust/include ${libdir}/llvm-rust/share ${libdir}/llvm-rust/lib/cmake"
-
-BBCLASSEXTEND = "native nativesdk"
--
2.49.0
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [OE-core] [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB
2025-10-15 9:59 [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB Deepesh.Varatharajan
2025-10-15 9:59 ` [PATCH V5 2/3] rust: Use llvm instead of rust-llvm Deepesh.Varatharajan
2025-10-15 9:59 ` [PATCH V5 3/3] rust: Drop rust-llvm Deepesh.Varatharajan
@ 2025-10-16 6:31 ` Richard Purdie
2025-10-16 7:07 ` Deepesh Varatharajan
2 siblings, 1 reply; 12+ messages in thread
From: Richard Purdie @ 2025-10-16 6:31 UTC (permalink / raw)
To: deepesh.varatharajan, openembedded-core; +Cc: Sundeep.Kokkonda
On Wed, 2025-10-15 at 02:59 -0700, Varatharajan, Deepesh via lists.openembedded.org wrote:
> From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>
> Rightnow rust depends on llvm instead of rust-llvm
>
> Setup in rust-llvm
> CFLAGS:remove = "-g"
> CXXFLAGS:remove = "-g"
>
> Setup in llvm
> DEBUG_LEVELFLAG = "-g1"
>
> As a result, the stage1 compiler crate binaries include debug symbols,
> increasing their size. These binaries are used to run tests inside QEMU.
> To accommodate this, increase the QEMU RAM allocation to 1024 MB.
>
> Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
> ---
> meta/lib/oeqa/selftest/cases/rust.py | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/meta/lib/oeqa/selftest/cases/rust.py b/meta/lib/oeqa/selftest/cases/rust.py
> index 95859a9eef..06acf53e9a 100644
> --- a/meta/lib/oeqa/selftest/cases/rust.py
> +++ b/meta/lib/oeqa/selftest/cases/rust.py
> @@ -102,8 +102,9 @@ class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
> testargs = exclude_fail_tests + " --no-doc --no-fail-fast --bless"
>
> # wrap the execution with a qemu instance.
> - # Tests are run with 512 tasks in parallel to execute all tests very quickly
> - with runqemu("core-image-minimal", runqemuparams = "nographic", qemuparams = "-m 512") as qemu:
> + # Set QEMU RAM to 1024MB to support running unit tests for the compiler crate, including larger
> + # test cases and parallel execution in the test environment.
> + with runqemu("core-image-minimal", runqemuparams = "nographic", qemuparams = "-m 1024") as qemu:
> # Copy remote-test-server to image through scp
> host_sys = get_bb_var("RUST_BUILD_SYS", "rust")
> ssh = SSHControl(ip=qemu.ip, logfile=qemu.sshlog, user="root")
This failed in testing:
https://autobuilder.yoctoproject.org/valkyrie/#/builders/42/builds/2522
I suspect some qemu platforms don't allow changing the memory size so easily?
Cheers,
Richard
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OE-core] [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB
2025-10-16 6:31 ` [OE-core] [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB Richard Purdie
@ 2025-10-16 7:07 ` Deepesh Varatharajan
0 siblings, 0 replies; 12+ messages in thread
From: Deepesh Varatharajan @ 2025-10-16 7:07 UTC (permalink / raw)
To: Richard Purdie, openembedded-core; +Cc: Sundeep.Kokkonda
On 16-10-2025 12:01, 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 Wed, 2025-10-15 at 02:59 -0700, Varatharajan, Deepesh via lists.openembedded.org wrote:
>> From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>>
>> Rightnow rust depends on llvm instead of rust-llvm
>>
>> Setup in rust-llvm
>> CFLAGS:remove = "-g"
>> CXXFLAGS:remove = "-g"
>>
>> Setup in llvm
>> DEBUG_LEVELFLAG = "-g1"
>>
>> As a result, the stage1 compiler crate binaries include debug symbols,
>> increasing their size. These binaries are used to run tests inside QEMU.
>> To accommodate this, increase the QEMU RAM allocation to 1024 MB.
>>
>> Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>> ---
>> meta/lib/oeqa/selftest/cases/rust.py | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/lib/oeqa/selftest/cases/rust.py b/meta/lib/oeqa/selftest/cases/rust.py
>> index 95859a9eef..06acf53e9a 100644
>> --- a/meta/lib/oeqa/selftest/cases/rust.py
>> +++ b/meta/lib/oeqa/selftest/cases/rust.py
>> @@ -102,8 +102,9 @@ class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
>> testargs = exclude_fail_tests + " --no-doc --no-fail-fast --bless"
>>
>> # wrap the execution with a qemu instance.
>> - # Tests are run with 512 tasks in parallel to execute all tests very quickly
>> - with runqemu("core-image-minimal", runqemuparams = "nographic", qemuparams = "-m 512") as qemu:
>> + # Set QEMU RAM to 1024MB to support running unit tests for the compiler crate, including larger
>> + # test cases and parallel execution in the test environment.
>> + with runqemu("core-image-minimal", runqemuparams = "nographic", qemuparams = "-m 1024") as qemu:
>> # Copy remote-test-server to image through scp
>> host_sys = get_bb_var("RUST_BUILD_SYS", "rust")
>> ssh = SSHControl(ip=qemu.ip, logfile=qemu.sshlog, user="root")
> This failed in testing:
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/42/builds/2522
>
> I suspect some qemu platforms don't allow changing the memory size so easily?
>
> Cheers,
>
> Richard
Hi Richard,
I had a look at the failure and noticed that this test run includes a
linux-firmware upgrade (20250917 → 20251011).
While it’s not confirmed yet, it’s possible that the updated firmware
may be affecting device initialization. Since
the log shows a warning indicating that the target did not reach the
login banner within 1000 seconds, confirming
that the system hangs shortly after starting likely around the time
virtio-gpu is initialized.
Additionally, I believe this issue is not related to the increased
memory allocation because the GCC oe-selftest,
which runs with 4096 MB of QEMU memory, completed successfully. I also
checked previous autobuilder runs without
this linux-firmware update which had these rust-llvm drop set of patches
and the qemuarm-tc build completed without
issues.
https://autobuilder.yoctoproject.org/valkyrie/?#/builders/42/builds/2519
Regards,
Deepesh
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OE-core] [PATCH V5 2/3] rust: Use llvm instead of rust-llvm
2025-10-15 9:59 ` [PATCH V5 2/3] rust: Use llvm instead of rust-llvm Deepesh.Varatharajan
@ 2025-10-17 6:01 ` Khem Raj
2025-10-18 6:42 ` Deepesh Varatharajan
2025-10-20 11:23 ` Ross Burton
1 sibling, 1 reply; 12+ messages in thread
From: Khem Raj @ 2025-10-17 6:01 UTC (permalink / raw)
To: deepesh.varatharajan; +Cc: openembedded-core, Sundeep.Kokkonda
I am seeing a build regression when using clang as default compiler
https://errors.yoctoproject.org/Errors/Details/885430/
PREFERRED_TOOLCHAIN_TARGET ?= "clang"
PREFERRED_TOOLCHAIN_SDK ?= "clang"
TOOLCHAIN_NATIVE:pn-rust ?= "clang"
TOOLCHAIN_NATIVE:pn-rust-native ?= "clang"
TOOLCHAIN_NATIVE:pn-nativesdk-rust ?= "clang"
On Wed, Oct 15, 2025 at 2:59 AM Varatharajan, Deepesh via
lists.openembedded.org
<deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote:
>
> From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>
> Updated the Rust build to depend on llvm 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 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 are copying the natively built `llvm-config` binary into the target sysroot and running
> it. However, this `llvm-config` has compile time dependencies on various other arch's LLVM
> libraries because native-llvm is built for all oe-core supported targets.
>
> Attempting to work around this by symlinking the missing libraries from the native sysroot
> into the target sysroot leads to mixed architectures in the final `.rlib`. Specifically,
> the object files extracted from those symlinked libraries within `librustc_llvm-<hash>.rlib`
> are built for the host, while others are correctly built for the target This results in linker
> failures due to file format not recognized.
>
> To resolve this, we now build llvm-target also for all oe-core supported architectures in
> addition to the native-llvm build. This ensures that `llvm-config` and all associated
> libraries are built for the correct target, eliminating cross-architecture contamination
> and linker issues.
>
> *We are enabling -DLLVM_INSTALL_UTILS=ON to ensure essential LLVM utilities like FileCheck
> are available, as they are required by the Rust build.
>
> Without this, the build fails with an error as below:
> | thread 'main' panicked at src/bootstrap/src/core/sanity.rs:315:21:
> | FileCheck executable "poky/build/tmp/work/x86_64-linux/rust-native/1.90.0/recipe-sysroot
> -native/usr/bin/FileCheck" does not exist
>
> *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 llvm
> -DLLVM_ENABLE_FFI=ON \
>
> *When multilibs enabled:
>
> llvm-config expects static libraries to be located in the lib directory rather than
> lib64. However, since we are copying the natively built llvm-config to target sysroot
> and running it and llvm-config doesn't know anything about lib64 existence. To accommodate
> this without breaking multilib behavior, we are creating a symlink from 'lib' to 'lib64'
> directory.
>
> 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.
>
> Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
> ---
> meta/recipes-devtools/clang/llvm_git.bb | 2 +-
> meta/recipes-devtools/rust/rust_1.90.0.bb | 39 ++++++++++++++++++++---
> 2 files changed, 36 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-devtools/clang/llvm_git.bb b/meta/recipes-devtools/clang/llvm_git.bb
> index d2b060ff88..2f47af8d7a 100644
> --- a/meta/recipes-devtools/clang/llvm_git.bb
> +++ b/meta/recipes-devtools/clang/llvm_git.bb
> @@ -27,7 +27,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 ?= ""
>
> @@ -37,6 +36,7 @@ HF[vardepvalue] = "${HF}"
>
> EXTRA_OECMAKE += "-DCMAKE_BUILD_TYPE=MinSizeRel \
> -DLLVM_ENABLE_BINDINGS=OFF \
> + -DLLVM_INSTALL_UTILS=ON \
> -DLLVM_ENABLE_FFI=ON \
> -DLLVM_ENABLE_RTTI=ON \
> -DLLVM_TARGETS_TO_BUILD='${LLVM_TARGETS_TO_BUILD}' \
> diff --git a/meta/recipes-devtools/rust/rust_1.90.0.bb b/meta/recipes-devtools/rust/rust_1.90.0.bb
> index 5d804c7398..0319d73b93 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 += "llvm"
> # 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,37 @@ python do_configure() {
> bb.build.exec_func("setup_cargo_environment", d)
> }
>
> +# llvm-config expects static libraries to be in the 'lib' directory rather than 'lib64' when
> +# multilibs enabled. Since we are copying the natively built llvm-config into the target sysroot
> +# and executing it there, it will default to searching in 'lib', as it is unaware of the 'lib64'
> +# directory. To ensure llvm-config can locate the necessary libraries, create a symlink from 'lib'
> +do_compile:append:class-target() {
> + # Ensure llvm-config can find static libraries in multilib setup
> + lib64_dir="${STAGING_DIR_TARGET}/usr/lib64"
> + lib_dir="${STAGING_DIR_TARGET}/usr/lib"
> +
> + if [ -d "$lib64_dir" ]; then
> + # If lib does not exist, symlink it to lib64
> + if [ ! -e "$lib_dir" ]; then
> + ln -s lib64 "$lib_dir"
> + fi
> +
> + # Only do per-file symlinking if lib is a real directory (not symlink)
> + if [ -d "$lib_dir" ] && [ ! -L "$lib_dir" ]; then
> + for lib64_file in "${lib64_dir}"/libLLVM*.a; do
> + if [ -e "$lib64_file" ]; then
> + lib_name=$(basename "${lib64_file}")
> + target_link="${lib_dir}/${lib_name}"
> +
> + if [ ! -e "${target_link}" ]; then
> + ln -s "../lib64/${lib_name}" "${target_link}"
> + fi
> + fi
> + done
> + fi
> + fi
> +}
> +
> rust_runx () {
> echo "COMPILE ${PN}" "$@"
>
> @@ -199,7 +230,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!
> --
> 2.49.0
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#224888): https://lists.openembedded.org/g/openembedded-core/message/224888
> Mute This Topic: https://lists.openembedded.org/mt/115768136/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OE-core] [PATCH V5 2/3] rust: Use llvm instead of rust-llvm
2025-10-17 6:01 ` [OE-core] " Khem Raj
@ 2025-10-18 6:42 ` Deepesh Varatharajan
2025-10-18 17:11 ` Khem Raj
0 siblings, 1 reply; 12+ messages in thread
From: Deepesh Varatharajan @ 2025-10-18 6:42 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-core, Sundeep.Kokkonda
On 17-10-2025 11:31, Khem Raj 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.
>
> I am seeing a build regression when using clang as default compiler
>
> https://errors.yoctoproject.org/Errors/Details/885430/
>
> PREFERRED_TOOLCHAIN_TARGET ?= "clang"
> PREFERRED_TOOLCHAIN_SDK ?= "clang"
> TOOLCHAIN_NATIVE:pn-rust ?= "clang"
> TOOLCHAIN_NATIVE:pn-rust-native ?= "clang"
> TOOLCHAIN_NATIVE:pn-nativesdk-rust ?= "clang"
Hi Khem,
WIth the above mentioned conf in local.conf, I tried building rust for
qemuarm and qemuarm64 quite
few times and the build completed successfully without any issues for
both native and target. Do I need
to add any other layers on top of poky ? Do you have any branch where I
can clone and reproduce the
issue ? Am I missing any step in reproducing the issue ?
Regards,
Deepesh
>
> On Wed, Oct 15, 2025 at 2:59 AM Varatharajan, Deepesh via
> lists.openembedded.org
> <deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote:
>> From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>>
>> Updated the Rust build to depend on llvm 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 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 are copying the natively built `llvm-config` binary into the target sysroot and running
>> it. However, this `llvm-config` has compile time dependencies on various other arch's LLVM
>> libraries because native-llvm is built for all oe-core supported targets.
>>
>> Attempting to work around this by symlinking the missing libraries from the native sysroot
>> into the target sysroot leads to mixed architectures in the final `.rlib`. Specifically,
>> the object files extracted from those symlinked libraries within `librustc_llvm-<hash>.rlib`
>> are built for the host, while others are correctly built for the target This results in linker
>> failures due to file format not recognized.
>>
>> To resolve this, we now build llvm-target also for all oe-core supported architectures in
>> addition to the native-llvm build. This ensures that `llvm-config` and all associated
>> libraries are built for the correct target, eliminating cross-architecture contamination
>> and linker issues.
>>
>> *We are enabling -DLLVM_INSTALL_UTILS=ON to ensure essential LLVM utilities like FileCheck
>> are available, as they are required by the Rust build.
>>
>> Without this, the build fails with an error as below:
>> | thread 'main' panicked at src/bootstrap/src/core/sanity.rs:315:21:
>> | FileCheck executable "poky/build/tmp/work/x86_64-linux/rust-native/1.90.0/recipe-sysroot
>> -native/usr/bin/FileCheck" does not exist
>>
>> *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 llvm
>> -DLLVM_ENABLE_FFI=ON \
>>
>> *When multilibs enabled:
>>
>> llvm-config expects static libraries to be located in the lib directory rather than
>> lib64. However, since we are copying the natively built llvm-config to target sysroot
>> and running it and llvm-config doesn't know anything about lib64 existence. To accommodate
>> this without breaking multilib behavior, we are creating a symlink from 'lib' to 'lib64'
>> directory.
>>
>> 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.
>>
>> Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>> ---
>> meta/recipes-devtools/clang/llvm_git.bb | 2 +-
>> meta/recipes-devtools/rust/rust_1.90.0.bb | 39 ++++++++++++++++++++---
>> 2 files changed, 36 insertions(+), 5 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/clang/llvm_git.bb b/meta/recipes-devtools/clang/llvm_git.bb
>> index d2b060ff88..2f47af8d7a 100644
>> --- a/meta/recipes-devtools/clang/llvm_git.bb
>> +++ b/meta/recipes-devtools/clang/llvm_git.bb
>> @@ -27,7 +27,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 ?= ""
>>
>> @@ -37,6 +36,7 @@ HF[vardepvalue] = "${HF}"
>>
>> EXTRA_OECMAKE += "-DCMAKE_BUILD_TYPE=MinSizeRel \
>> -DLLVM_ENABLE_BINDINGS=OFF \
>> + -DLLVM_INSTALL_UTILS=ON \
>> -DLLVM_ENABLE_FFI=ON \
>> -DLLVM_ENABLE_RTTI=ON \
>> -DLLVM_TARGETS_TO_BUILD='${LLVM_TARGETS_TO_BUILD}' \
>> diff --git a/meta/recipes-devtools/rust/rust_1.90.0.bb b/meta/recipes-devtools/rust/rust_1.90.0.bb
>> index 5d804c7398..0319d73b93 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 += "llvm"
>> # 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,37 @@ python do_configure() {
>> bb.build.exec_func("setup_cargo_environment", d)
>> }
>>
>> +# llvm-config expects static libraries to be in the 'lib' directory rather than 'lib64' when
>> +# multilibs enabled. Since we are copying the natively built llvm-config into the target sysroot
>> +# and executing it there, it will default to searching in 'lib', as it is unaware of the 'lib64'
>> +# directory. To ensure llvm-config can locate the necessary libraries, create a symlink from 'lib'
>> +do_compile:append:class-target() {
>> + # Ensure llvm-config can find static libraries in multilib setup
>> + lib64_dir="${STAGING_DIR_TARGET}/usr/lib64"
>> + lib_dir="${STAGING_DIR_TARGET}/usr/lib"
>> +
>> + if [ -d "$lib64_dir" ]; then
>> + # If lib does not exist, symlink it to lib64
>> + if [ ! -e "$lib_dir" ]; then
>> + ln -s lib64 "$lib_dir"
>> + fi
>> +
>> + # Only do per-file symlinking if lib is a real directory (not symlink)
>> + if [ -d "$lib_dir" ] && [ ! -L "$lib_dir" ]; then
>> + for lib64_file in "${lib64_dir}"/libLLVM*.a; do
>> + if [ -e "$lib64_file" ]; then
>> + lib_name=$(basename "${lib64_file}")
>> + target_link="${lib_dir}/${lib_name}"
>> +
>> + if [ ! -e "${target_link}" ]; then
>> + ln -s "../lib64/${lib_name}" "${target_link}"
>> + fi
>> + fi
>> + done
>> + fi
>> + fi
>> +}
>> +
>> rust_runx () {
>> echo "COMPILE ${PN}" "$@"
>>
>> @@ -199,7 +230,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!
>> --
>> 2.49.0
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#224888): https://lists.openembedded.org/g/openembedded-core/message/224888
>> Mute This Topic: https://lists.openembedded.org/mt/115768136/1997914
>> Group Owner: openembedded-core+owner@lists.openembedded.org
>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OE-core] [PATCH V5 2/3] rust: Use llvm instead of rust-llvm
2025-10-18 6:42 ` Deepesh Varatharajan
@ 2025-10-18 17:11 ` Khem Raj
2025-10-21 6:09 ` Deepesh Varatharajan
0 siblings, 1 reply; 12+ messages in thread
From: Khem Raj @ 2025-10-18 17:11 UTC (permalink / raw)
To: Deepesh Varatharajan; +Cc: openembedded-core, Sundeep.Kokkonda
On Fri, Oct 17, 2025 at 11:42 PM Deepesh Varatharajan
<deepesh.varatharajan@windriver.com> wrote:
>
>
> On 17-10-2025 11:31, Khem Raj 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.
> >
> > I am seeing a build regression when using clang as default compiler
> >
> > https://errors.yoctoproject.org/Errors/Details/885430/
> >
> > PREFERRED_TOOLCHAIN_TARGET ?= "clang"
> > PREFERRED_TOOLCHAIN_SDK ?= "clang"
> > TOOLCHAIN_NATIVE:pn-rust ?= "clang"
> > TOOLCHAIN_NATIVE:pn-rust-native ?= "clang"
> > TOOLCHAIN_NATIVE:pn-nativesdk-rust ?= "clang"
> Hi Khem,
>
> WIth the above mentioned conf in local.conf, I tried building rust for
> qemuarm and qemuarm64 quite
> few times and the build completed successfully without any issues for
> both native and target. Do I need
> to add any other layers on top of poky ? Do you have any branch where I
> can clone and reproduce the
> issue ? Am I missing any step in reproducing the issue ?
>
Yeah, I missed a setting which I think could be the reason
TC_CXX_RUNTIME = "llvm"
> Regards,
> Deepesh
> >
> > On Wed, Oct 15, 2025 at 2:59 AM Varatharajan, Deepesh via
> > lists.openembedded.org
> > <deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote:
> >> From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
> >>
> >> Updated the Rust build to depend on llvm 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 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 are copying the natively built `llvm-config` binary into the target sysroot and running
> >> it. However, this `llvm-config` has compile time dependencies on various other arch's LLVM
> >> libraries because native-llvm is built for all oe-core supported targets.
> >>
> >> Attempting to work around this by symlinking the missing libraries from the native sysroot
> >> into the target sysroot leads to mixed architectures in the final `.rlib`. Specifically,
> >> the object files extracted from those symlinked libraries within `librustc_llvm-<hash>.rlib`
> >> are built for the host, while others are correctly built for the target This results in linker
> >> failures due to file format not recognized.
> >>
> >> To resolve this, we now build llvm-target also for all oe-core supported architectures in
> >> addition to the native-llvm build. This ensures that `llvm-config` and all associated
> >> libraries are built for the correct target, eliminating cross-architecture contamination
> >> and linker issues.
> >>
> >> *We are enabling -DLLVM_INSTALL_UTILS=ON to ensure essential LLVM utilities like FileCheck
> >> are available, as they are required by the Rust build.
> >>
> >> Without this, the build fails with an error as below:
> >> | thread 'main' panicked at src/bootstrap/src/core/sanity.rs:315:21:
> >> | FileCheck executable "poky/build/tmp/work/x86_64-linux/rust-native/1.90.0/recipe-sysroot
> >> -native/usr/bin/FileCheck" does not exist
> >>
> >> *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 llvm
> >> -DLLVM_ENABLE_FFI=ON \
> >>
> >> *When multilibs enabled:
> >>
> >> llvm-config expects static libraries to be located in the lib directory rather than
> >> lib64. However, since we are copying the natively built llvm-config to target sysroot
> >> and running it and llvm-config doesn't know anything about lib64 existence. To accommodate
> >> this without breaking multilib behavior, we are creating a symlink from 'lib' to 'lib64'
> >> directory.
> >>
> >> 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.
> >>
> >> Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
> >> ---
> >> meta/recipes-devtools/clang/llvm_git.bb | 2 +-
> >> meta/recipes-devtools/rust/rust_1.90.0.bb | 39 ++++++++++++++++++++---
> >> 2 files changed, 36 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/meta/recipes-devtools/clang/llvm_git.bb b/meta/recipes-devtools/clang/llvm_git.bb
> >> index d2b060ff88..2f47af8d7a 100644
> >> --- a/meta/recipes-devtools/clang/llvm_git.bb
> >> +++ b/meta/recipes-devtools/clang/llvm_git.bb
> >> @@ -27,7 +27,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 ?= ""
> >>
> >> @@ -37,6 +36,7 @@ HF[vardepvalue] = "${HF}"
> >>
> >> EXTRA_OECMAKE += "-DCMAKE_BUILD_TYPE=MinSizeRel \
> >> -DLLVM_ENABLE_BINDINGS=OFF \
> >> + -DLLVM_INSTALL_UTILS=ON \
> >> -DLLVM_ENABLE_FFI=ON \
> >> -DLLVM_ENABLE_RTTI=ON \
> >> -DLLVM_TARGETS_TO_BUILD='${LLVM_TARGETS_TO_BUILD}' \
> >> diff --git a/meta/recipes-devtools/rust/rust_1.90.0.bb b/meta/recipes-devtools/rust/rust_1.90.0.bb
> >> index 5d804c7398..0319d73b93 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 += "llvm"
> >> # 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,37 @@ python do_configure() {
> >> bb.build.exec_func("setup_cargo_environment", d)
> >> }
> >>
> >> +# llvm-config expects static libraries to be in the 'lib' directory rather than 'lib64' when
> >> +# multilibs enabled. Since we are copying the natively built llvm-config into the target sysroot
> >> +# and executing it there, it will default to searching in 'lib', as it is unaware of the 'lib64'
> >> +# directory. To ensure llvm-config can locate the necessary libraries, create a symlink from 'lib'
> >> +do_compile:append:class-target() {
> >> + # Ensure llvm-config can find static libraries in multilib setup
> >> + lib64_dir="${STAGING_DIR_TARGET}/usr/lib64"
> >> + lib_dir="${STAGING_DIR_TARGET}/usr/lib"
> >> +
> >> + if [ -d "$lib64_dir" ]; then
> >> + # If lib does not exist, symlink it to lib64
> >> + if [ ! -e "$lib_dir" ]; then
> >> + ln -s lib64 "$lib_dir"
> >> + fi
> >> +
> >> + # Only do per-file symlinking if lib is a real directory (not symlink)
> >> + if [ -d "$lib_dir" ] && [ ! -L "$lib_dir" ]; then
> >> + for lib64_file in "${lib64_dir}"/libLLVM*.a; do
> >> + if [ -e "$lib64_file" ]; then
> >> + lib_name=$(basename "${lib64_file}")
> >> + target_link="${lib_dir}/${lib_name}"
> >> +
> >> + if [ ! -e "${target_link}" ]; then
> >> + ln -s "../lib64/${lib_name}" "${target_link}"
> >> + fi
> >> + fi
> >> + done
> >> + fi
> >> + fi
> >> +}
> >> +
> >> rust_runx () {
> >> echo "COMPILE ${PN}" "$@"
> >>
> >> @@ -199,7 +230,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!
> >> --
> >> 2.49.0
> >>
> >>
> >> -=-=-=-=-=-=-=-=-=-=-=-
> >> Links: You receive all messages sent to this group.
> >> View/Reply Online (#224888): https://lists.openembedded.org/g/openembedded-core/message/224888
> >> Mute This Topic: https://lists.openembedded.org/mt/115768136/1997914
> >> Group Owner: openembedded-core+owner@lists.openembedded.org
> >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> >> -=-=-=-=-=-=-=-=-=-=-=-
> >>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OE-core] [PATCH V5 2/3] rust: Use llvm instead of rust-llvm
2025-10-15 9:59 ` [PATCH V5 2/3] rust: Use llvm instead of rust-llvm Deepesh.Varatharajan
2025-10-17 6:01 ` [OE-core] " Khem Raj
@ 2025-10-20 11:23 ` Ross Burton
2025-10-20 14:40 ` Ross Burton
1 sibling, 1 reply; 12+ messages in thread
From: Ross Burton @ 2025-10-20 11:23 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
Cc: Sundeep.Kokkonda@windriver.com,
deepesh.varatharajan@windriver.com
Hi,
> On 15 Oct 2025, at 10:59, Varatharajan, Deepesh via lists.openembedded.org <deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote:
> Updated the Rust build to depend on llvm instead.
Because I was curious, I looked at the build stats before and after this series being merged. Here are the diffs for cputime and walltime when I built llvm-native/rust-llvm-native and rust-native:
PKG TASK ABSDIFF RELDIFF CPUTIME1 -> CPUTIME2
- rust-llvm-native do_compile -12241.8s -100.0% 12241.8s -> 0.0s
- rust-llvm-native do_unpack -31.4s -100.0% 31.4s -> 0.0s
- rust-llvm-native do_configure -9.4s -100.0% 9.4s -> 0.0s
- rust-llvm-native do_populate_sysroot -6.2s -100.0% 6.2s -> 0.0s
+ llvm-project-source-21.1.3 do_patch 5.8s +inf% 0.0s -> 5.8s
rust-native do_populate_sysroot 9.5s +323.0% 2.9s -> 12.5s
+ llvm-native do_configure 12.9s +inf% 0.0s -> 12.9s
+ llvm-native do_populate_sysroot 18.6s +inf% 0.0s -> 18.6s
+ llvm-project-source-21.1.3 do_unpack 20.0s +inf% 0.0s -> 20.0s
+ llvm-tblgen-native do_configure 29.0s +inf% 0.0s -> 29.0s
+ llvm-tblgen-native do_compile 593.1s +inf% 0.0s -> 593.1s
rust-native do_install 1724.2s +26.1% 6611.3s -> 8335.5s
+ llvm-native do_compile 12051.6s +inf% 0.0s -> 12051.6s
PKG TASK ABSDIFF RELDIFF WALLTIME1 -> WALLTIME2
- rust-llvm-native do_compile -401.1s -100.0% 401.1s -> 0.0s
- rust-llvm-native do_unpack -23.0s -100.0% 23.0s -> 0.0s
rust-native do_unpack -21.3s -42.5% 50.3s -> 28.9s
- rust-llvm-native do_configure -9.0s -100.0% 9.0s -> 0.0s
+ llvm-project-source-21.1.3 do_unpack 7.0s +inf% 0.0s -> 7.0s
+ llvm-native do_configure 12.3s +inf% 0.0s -> 12.3s
+ llvm-tblgen-native do_configure 28.5s +inf% 0.0s -> 28.5s
+ llvm-tblgen-native do_compile 30.1s +inf% 0.0s -> 30.1s
rust-native do_install 33.4s +6.0% 553.4s -> 586.8s
+ llvm-native do_compile 378.0s +inf% 0.0s -> 378.0s
For llvm vs rust-llvm, I’ve a local tweak to not build some of the GPU backends (as they take a long time) so it’s actually comparing like-for-like, and it’s good to see that the compile time is close. It’s slightly faster in llvm even though it’s building more backends, so I’m glad my build tweaking was useful.
However, rust-native takes 26% more cpu time (just 6% more wall time, due to parallelisation). I’m wondering if this is fallout from using -Os instead of -O2, or something else about how we’re building rust-llvm vs llvm. Insights welcome, but I’ll likely fire a test build without -Os to see how that impacts the numbers later.
Cheers,
Ross
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OE-core] [PATCH V5 2/3] rust: Use llvm instead of rust-llvm
2025-10-20 11:23 ` Ross Burton
@ 2025-10-20 14:40 ` Ross Burton
2025-10-20 15:11 ` Khem Raj
0 siblings, 1 reply; 12+ messages in thread
From: Ross Burton @ 2025-10-20 14:40 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
Cc: Sundeep.Kokkonda@windriver.com,
deepesh.varatharajan@windriver.com
On 20 Oct 2025, at 12:23, Ross Burton via lists.openembedded.org <ross.burton=arm.com@lists.openembedded.org> wrote:
>
> Hi,
>
>> On 15 Oct 2025, at 10:59, Varatharajan, Deepesh via lists.openembedded.org <deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote:
>> Updated the Rust build to depend on llvm instead.
>
> Because I was curious, I looked at the build stats before and after this series being merged. Here are the diffs for cputime and walltime when I built llvm-native/rust-llvm-native and rust-native:
>
> PKG TASK ABSDIFF RELDIFF CPUTIME1 -> CPUTIME2
> - rust-llvm-native do_compile -12241.8s -100.0% 12241.8s -> 0.0s
> - rust-llvm-native do_unpack -31.4s -100.0% 31.4s -> 0.0s
> - rust-llvm-native do_configure -9.4s -100.0% 9.4s -> 0.0s
> - rust-llvm-native do_populate_sysroot -6.2s -100.0% 6.2s -> 0.0s
> + llvm-project-source-21.1.3 do_patch 5.8s +inf% 0.0s -> 5.8s
> rust-native do_populate_sysroot 9.5s +323.0% 2.9s -> 12.5s
> + llvm-native do_configure 12.9s +inf% 0.0s -> 12.9s
> + llvm-native do_populate_sysroot 18.6s +inf% 0.0s -> 18.6s
> + llvm-project-source-21.1.3 do_unpack 20.0s +inf% 0.0s -> 20.0s
> + llvm-tblgen-native do_configure 29.0s +inf% 0.0s -> 29.0s
> + llvm-tblgen-native do_compile 593.1s +inf% 0.0s -> 593.1s
> rust-native do_install 1724.2s +26.1% 6611.3s -> 8335.5s
> + llvm-native do_compile 12051.6s +inf% 0.0s -> 12051.6s
>
> PKG TASK ABSDIFF RELDIFF WALLTIME1 -> WALLTIME2
> - rust-llvm-native do_compile -401.1s -100.0% 401.1s -> 0.0s
> - rust-llvm-native do_unpack -23.0s -100.0% 23.0s -> 0.0s
> rust-native do_unpack -21.3s -42.5% 50.3s -> 28.9s
> - rust-llvm-native do_configure -9.0s -100.0% 9.0s -> 0.0s
> + llvm-project-source-21.1.3 do_unpack 7.0s +inf% 0.0s -> 7.0s
> + llvm-native do_configure 12.3s +inf% 0.0s -> 12.3s
> + llvm-tblgen-native do_configure 28.5s +inf% 0.0s -> 28.5s
> + llvm-tblgen-native do_compile 30.1s +inf% 0.0s -> 30.1s
> rust-native do_install 33.4s +6.0% 553.4s -> 586.8s
> + llvm-native do_compile 378.0s +inf% 0.0s -> 378.0s
>
> For llvm vs rust-llvm, I’ve a local tweak to not build some of the GPU backends (as they take a long time) so it’s actually comparing like-for-like, and it’s good to see that the compile time is close. It’s slightly faster in llvm even though it’s building more backends, so I’m glad my build tweaking was useful.
>
> However, rust-native takes 26% more cpu time (just 6% more wall time, due to parallelisation). I’m wondering if this is fallout from using -Os instead of -O2, or something else about how we’re building rust-llvm vs llvm. Insights welcome, but I’ll likely fire a test build without -Os to see how that impacts the numbers later.
Followup, comparing current master to master but with LLVM built as RelWithDebInfo instead of MinSizeRel:
PKG TASK ABSDIFF RELDIFF CPUTIME1 -> CPUTIME2
rust-native do_install -1690.4s -20.3% 8335.5s -> 6645.1s
llvm-native do_compile 6081.7s +50.5% 12051.6s -> 18133.3s
Cumulative cputime:
4117.4s +19.5% 5:52:36.1 (21156.1s) -> 7:01:13.5 (25273.5s)
PKG TASK ABSDIFF RELDIFF WALLTIME1 -> WALLTIME2
rust-native do_install 24.0s +4.1% 586.8s -> 610.8s
llvm-native do_compile 238.9s +63.2% 378.0s -> 616.8s
Cumulative walltime:
251.3s +22.8% 18:24.7 (1104.7s) -> 22:36.0 (1356.0s)
So rust builds a bit faster, but LLVM is a lot slower to build, with a net result that the build is actually slower overall. I’m happy with the choice to use MinSizeRel in LLVM.
Ross
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OE-core] [PATCH V5 2/3] rust: Use llvm instead of rust-llvm
2025-10-20 14:40 ` Ross Burton
@ 2025-10-20 15:11 ` Khem Raj
0 siblings, 0 replies; 12+ messages in thread
From: Khem Raj @ 2025-10-20 15:11 UTC (permalink / raw)
To: ross.burton
Cc: openembedded-core@lists.openembedded.org,
Sundeep.Kokkonda@windriver.com,
deepesh.varatharajan@windriver.com
On Mon, Oct 20, 2025 at 7:40 AM Ross Burton via lists.openembedded.org
<ross.burton=arm.com@lists.openembedded.org> wrote:
>
> On 20 Oct 2025, at 12:23, Ross Burton via lists.openembedded.org <ross.burton=arm.com@lists.openembedded.org> wrote:
> >
> > Hi,
> >
> >> On 15 Oct 2025, at 10:59, Varatharajan, Deepesh via lists.openembedded.org <deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote:
> >> Updated the Rust build to depend on llvm instead.
> >
> > Because I was curious, I looked at the build stats before and after this series being merged. Here are the diffs for cputime and walltime when I built llvm-native/rust-llvm-native and rust-native:
> >
> > PKG TASK ABSDIFF RELDIFF CPUTIME1 -> CPUTIME2
> > - rust-llvm-native do_compile -12241.8s -100.0% 12241.8s -> 0.0s
> > - rust-llvm-native do_unpack -31.4s -100.0% 31.4s -> 0.0s
> > - rust-llvm-native do_configure -9.4s -100.0% 9.4s -> 0.0s
> > - rust-llvm-native do_populate_sysroot -6.2s -100.0% 6.2s -> 0.0s
> > + llvm-project-source-21.1.3 do_patch 5.8s +inf% 0.0s -> 5.8s
> > rust-native do_populate_sysroot 9.5s +323.0% 2.9s -> 12.5s
> > + llvm-native do_configure 12.9s +inf% 0.0s -> 12.9s
> > + llvm-native do_populate_sysroot 18.6s +inf% 0.0s -> 18.6s
> > + llvm-project-source-21.1.3 do_unpack 20.0s +inf% 0.0s -> 20.0s
> > + llvm-tblgen-native do_configure 29.0s +inf% 0.0s -> 29.0s
> > + llvm-tblgen-native do_compile 593.1s +inf% 0.0s -> 593.1s
> > rust-native do_install 1724.2s +26.1% 6611.3s -> 8335.5s
> > + llvm-native do_compile 12051.6s +inf% 0.0s -> 12051.6s
> >
> > PKG TASK ABSDIFF RELDIFF WALLTIME1 -> WALLTIME2
> > - rust-llvm-native do_compile -401.1s -100.0% 401.1s -> 0.0s
> > - rust-llvm-native do_unpack -23.0s -100.0% 23.0s -> 0.0s
> > rust-native do_unpack -21.3s -42.5% 50.3s -> 28.9s
> > - rust-llvm-native do_configure -9.0s -100.0% 9.0s -> 0.0s
> > + llvm-project-source-21.1.3 do_unpack 7.0s +inf% 0.0s -> 7.0s
> > + llvm-native do_configure 12.3s +inf% 0.0s -> 12.3s
> > + llvm-tblgen-native do_configure 28.5s +inf% 0.0s -> 28.5s
> > + llvm-tblgen-native do_compile 30.1s +inf% 0.0s -> 30.1s
> > rust-native do_install 33.4s +6.0% 553.4s -> 586.8s
> > + llvm-native do_compile 378.0s +inf% 0.0s -> 378.0s
> >
> > For llvm vs rust-llvm, I’ve a local tweak to not build some of the GPU backends (as they take a long time) so it’s actually comparing like-for-like, and it’s good to see that the compile time is close. It’s slightly faster in llvm even though it’s building more backends, so I’m glad my build tweaking was useful.
> >
> > However, rust-native takes 26% more cpu time (just 6% more wall time, due to parallelisation). I’m wondering if this is fallout from using -Os instead of -O2, or something else about how we’re building rust-llvm vs llvm. Insights welcome, but I’ll likely fire a test build without -Os to see how that impacts the numbers later.
>
> Followup, comparing current master to master but with LLVM built as RelWithDebInfo instead of MinSizeRel:
>
> PKG TASK ABSDIFF RELDIFF CPUTIME1 -> CPUTIME2
> rust-native do_install -1690.4s -20.3% 8335.5s -> 6645.1s
> llvm-native do_compile 6081.7s +50.5% 12051.6s -> 18133.3s
>
> Cumulative cputime:
> 4117.4s +19.5% 5:52:36.1 (21156.1s) -> 7:01:13.5 (25273.5s)
>
>
> PKG TASK ABSDIFF RELDIFF WALLTIME1 -> WALLTIME2
> rust-native do_install 24.0s +4.1% 586.8s -> 610.8s
> llvm-native do_compile 238.9s +63.2% 378.0s -> 616.8s
>
> Cumulative walltime:
> 251.3s +22.8% 18:24.7 (1104.7s) -> 22:36.0 (1356.0s)
>
> So rust builds a bit faster, but LLVM is a lot slower to build, with a net result that the build is actually slower overall. I’m happy with the choice to use MinSizeRel in LLVM.
A large set of users of OE would not build compiler as often as some
system build engineers who build distros for them will do, so I wonder
how fast is resulting compiler in compiling applications, because in
such
settings it will be used in often and save a lot of time for users
such that spending extra time in compiling it in OE can be justified.
Of couse I am not recommending that
OE adopts that option as default.
>
> Ross
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#225121): https://lists.openembedded.org/g/openembedded-core/message/225121
> Mute This Topic: https://lists.openembedded.org/mt/115768136/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [OE-core] [PATCH V5 2/3] rust: Use llvm instead of rust-llvm
2025-10-18 17:11 ` Khem Raj
@ 2025-10-21 6:09 ` Deepesh Varatharajan
0 siblings, 0 replies; 12+ messages in thread
From: Deepesh Varatharajan @ 2025-10-21 6:09 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-core, Sundeep.Kokkonda, Ross Burton
On 18-10-2025 22:41, Khem Raj 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 Fri, Oct 17, 2025 at 11:42 PM Deepesh Varatharajan
> <deepesh.varatharajan@windriver.com> wrote:
>>
>> On 17-10-2025 11:31, Khem Raj 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.
>>>
>>> I am seeing a build regression when using clang as default compiler
>>>
>>> https://errors.yoctoproject.org/Errors/Details/885430/
>>>
>>> PREFERRED_TOOLCHAIN_TARGET ?= "clang"
>>> PREFERRED_TOOLCHAIN_SDK ?= "clang"
>>> TOOLCHAIN_NATIVE:pn-rust ?= "clang"
>>> TOOLCHAIN_NATIVE:pn-rust-native ?= "clang"
>>> TOOLCHAIN_NATIVE:pn-nativesdk-rust ?= "clang"
>> Hi Khem,
>>
>> WIth the above mentioned conf in local.conf, I tried building rust for
>> qemuarm and qemuarm64 quite
>> few times and the build completed successfully without any issues for
>> both native and target. Do I need
>> to add any other layers on top of poky ? Do you have any branch where I
>> can clone and reproduce the
>> issue ? Am I missing any step in reproducing the issue ?
>>
> Yeah, I missed a setting which I think could be the reason
>
> TC_CXX_RUNTIME = "llvm"
Hi Khem,
After adding the above in locl.conf, reproduced the issue. I've looked
into the issue and
here’s what I found:
Currently, both rust-native and rust-target rely on the natively built
llvm-config binary.
However, upon inspecting the runtime dependencies of llvm-config, I
noticed the following:
$ ldd ./llvm-config
linux-vdso.so.1 => (0x00007ffdec9eb000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
As shown, llvm-config is linked against libstdc++. Meanwhile, we're
enforcing Rust to be
built using libc++, and this mismatch is causing symbol resolution
issues at runtime.
To address the ABI mismatch, I tried building llvm-native with libc++ by
introducing a
dependency on libcxx-native. However, this leads to a circular dependency:
>llvm-native depends on libcxx-native
>libcxx-native depends on clang-native
>clang-native depends back on llvm-native
This cycle blocks the build.
One possible solution could be to create a separate llvm-config recipe
that builds with a
dependency on libcxx-native, and have Rust depend on that version
specifically.
Do we have any alternative ways to break this circular dependency?
Regards,
Deepesh
>
>
>> Regards,
>> Deepesh
>>> On Wed, Oct 15, 2025 at 2:59 AM Varatharajan, Deepesh via
>>> lists.openembedded.org
>>> <deepesh.varatharajan=windriver.com@lists.openembedded.org> wrote:
>>>> From: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>>>>
>>>> Updated the Rust build to depend on llvm 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 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 are copying the natively built `llvm-config` binary into the target sysroot and running
>>>> it. However, this `llvm-config` has compile time dependencies on various other arch's LLVM
>>>> libraries because native-llvm is built for all oe-core supported targets.
>>>>
>>>> Attempting to work around this by symlinking the missing libraries from the native sysroot
>>>> into the target sysroot leads to mixed architectures in the final `.rlib`. Specifically,
>>>> the object files extracted from those symlinked libraries within `librustc_llvm-<hash>.rlib`
>>>> are built for the host, while others are correctly built for the target This results in linker
>>>> failures due to file format not recognized.
>>>>
>>>> To resolve this, we now build llvm-target also for all oe-core supported architectures in
>>>> addition to the native-llvm build. This ensures that `llvm-config` and all associated
>>>> libraries are built for the correct target, eliminating cross-architecture contamination
>>>> and linker issues.
>>>>
>>>> *We are enabling -DLLVM_INSTALL_UTILS=ON to ensure essential LLVM utilities like FileCheck
>>>> are available, as they are required by the Rust build.
>>>>
>>>> Without this, the build fails with an error as below:
>>>> | thread 'main' panicked at src/bootstrap/src/core/sanity.rs:315:21:
>>>> | FileCheck executable "poky/build/tmp/work/x86_64-linux/rust-native/1.90.0/recipe-sysroot
>>>> -native/usr/bin/FileCheck" does not exist
>>>>
>>>> *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 llvm
>>>> -DLLVM_ENABLE_FFI=ON \
>>>>
>>>> *When multilibs enabled:
>>>>
>>>> llvm-config expects static libraries to be located in the lib directory rather than
>>>> lib64. However, since we are copying the natively built llvm-config to target sysroot
>>>> and running it and llvm-config doesn't know anything about lib64 existence. To accommodate
>>>> this without breaking multilib behavior, we are creating a symlink from 'lib' to 'lib64'
>>>> directory.
>>>>
>>>> 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.
>>>>
>>>> Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
>>>> ---
>>>> meta/recipes-devtools/clang/llvm_git.bb | 2 +-
>>>> meta/recipes-devtools/rust/rust_1.90.0.bb | 39 ++++++++++++++++++++---
>>>> 2 files changed, 36 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/meta/recipes-devtools/clang/llvm_git.bb b/meta/recipes-devtools/clang/llvm_git.bb
>>>> index d2b060ff88..2f47af8d7a 100644
>>>> --- a/meta/recipes-devtools/clang/llvm_git.bb
>>>> +++ b/meta/recipes-devtools/clang/llvm_git.bb
>>>> @@ -27,7 +27,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 ?= ""
>>>>
>>>> @@ -37,6 +36,7 @@ HF[vardepvalue] = "${HF}"
>>>>
>>>> EXTRA_OECMAKE += "-DCMAKE_BUILD_TYPE=MinSizeRel \
>>>> -DLLVM_ENABLE_BINDINGS=OFF \
>>>> + -DLLVM_INSTALL_UTILS=ON \
>>>> -DLLVM_ENABLE_FFI=ON \
>>>> -DLLVM_ENABLE_RTTI=ON \
>>>> -DLLVM_TARGETS_TO_BUILD='${LLVM_TARGETS_TO_BUILD}' \
>>>> diff --git a/meta/recipes-devtools/rust/rust_1.90.0.bb b/meta/recipes-devtools/rust/rust_1.90.0.bb
>>>> index 5d804c7398..0319d73b93 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 += "llvm"
>>>> # 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,37 @@ python do_configure() {
>>>> bb.build.exec_func("setup_cargo_environment", d)
>>>> }
>>>>
>>>> +# llvm-config expects static libraries to be in the 'lib' directory rather than 'lib64' when
>>>> +# multilibs enabled. Since we are copying the natively built llvm-config into the target sysroot
>>>> +# and executing it there, it will default to searching in 'lib', as it is unaware of the 'lib64'
>>>> +# directory. To ensure llvm-config can locate the necessary libraries, create a symlink from 'lib'
>>>> +do_compile:append:class-target() {
>>>> + # Ensure llvm-config can find static libraries in multilib setup
>>>> + lib64_dir="${STAGING_DIR_TARGET}/usr/lib64"
>>>> + lib_dir="${STAGING_DIR_TARGET}/usr/lib"
>>>> +
>>>> + if [ -d "$lib64_dir" ]; then
>>>> + # If lib does not exist, symlink it to lib64
>>>> + if [ ! -e "$lib_dir" ]; then
>>>> + ln -s lib64 "$lib_dir"
>>>> + fi
>>>> +
>>>> + # Only do per-file symlinking if lib is a real directory (not symlink)
>>>> + if [ -d "$lib_dir" ] && [ ! -L "$lib_dir" ]; then
>>>> + for lib64_file in "${lib64_dir}"/libLLVM*.a; do
>>>> + if [ -e "$lib64_file" ]; then
>>>> + lib_name=$(basename "${lib64_file}")
>>>> + target_link="${lib_dir}/${lib_name}"
>>>> +
>>>> + if [ ! -e "${target_link}" ]; then
>>>> + ln -s "../lib64/${lib_name}" "${target_link}"
>>>> + fi
>>>> + fi
>>>> + done
>>>> + fi
>>>> + fi
>>>> +}
>>>> +
>>>> rust_runx () {
>>>> echo "COMPILE ${PN}" "$@"
>>>>
>>>> @@ -199,7 +230,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!
>>>> --
>>>> 2.49.0
>>>>
>>>>
>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>> Links: You receive all messages sent to this group.
>>>> View/Reply Online (#224888): https://lists.openembedded.org/g/openembedded-core/message/224888
>>>> Mute This Topic: https://lists.openembedded.org/mt/115768136/1997914
>>>> Group Owner: openembedded-core+owner@lists.openembedded.org
>>>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
>>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2025-10-21 6:09 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-15 9:59 [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB Deepesh.Varatharajan
2025-10-15 9:59 ` [PATCH V5 2/3] rust: Use llvm instead of rust-llvm Deepesh.Varatharajan
2025-10-17 6:01 ` [OE-core] " Khem Raj
2025-10-18 6:42 ` Deepesh Varatharajan
2025-10-18 17:11 ` Khem Raj
2025-10-21 6:09 ` Deepesh Varatharajan
2025-10-20 11:23 ` Ross Burton
2025-10-20 14:40 ` Ross Burton
2025-10-20 15:11 ` Khem Raj
2025-10-15 9:59 ` [PATCH V5 3/3] rust: Drop rust-llvm Deepesh.Varatharajan
2025-10-16 6:31 ` [OE-core] [PATCH V5 1/3] rust: Increase QEMU size to 1024 MB Richard Purdie
2025-10-16 7:07 ` Deepesh Varatharajan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox