Bug 16026

Summary: Recent rust changes to use external LLVM breaks rust with clang + llvm runtime
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Khem Raj <raj.khem>
Component: devtools / tool chainAssignee: Deepesh Varatharajan <deepesh.varatharajan>
Status: NEW --- QA Contact:
Severity: normal    
Priority: Medium+ CC: meta.mr.watcher, meta.watcher, raj.khem, randy.macleod, ross.burton, tim.orling
Version: unspecified   
Target Milestone: 6.1 M3   
Hardware: All   
OS: Multiple   
See Also: https://bugzilla.yoctoproject.org/show_bug.cgi?id=16360
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know
Attachments:
Description Flags
POC patch none

Description Khem Raj 2025-10-21 17:43:32 UTC 
We have optimized the build times by making rust use external llvm which is a standalone recipe and is also shared with clang and other llvm tools. This has caused a regression in building rust for systems which used clang and llvm runtime as default. 

TC_CXX_RUNTIME = "llvm"
PREFERRED_TOOLCHAIN_TARGET = "clang"
PREFERRED_TOOLCHAIN_SDK = "clang"
DISTRO_FEATURES:append = "ld-is-lld"

This makes clang toolchain to default to using libc++ and compiler-rt for c/c++ runtime for target packages and sdk packages but native packages are still built using gcc and gcc runtime ( libgcc + libstdc++ ) on build host. 

Therefore llvm-native is built using libstdc++, when rust uses the elements of this llvm-native e.g. llvm-config, it decides that we are to link with libstdc++ but system toolchains are defaulting to libc++, so this causes a conflict as the two C++ standard libraries are not drop-in replacement, the linking stage gets some undefined symbols because of this gap.

It worked in the past because rust boostrapped with its own llvm and we could build a functional native clang toolchain which could be used to build rust-llvm-native and it would rightly link with chosen runtime. Now this step is short circuited.

Since LLVM is split out of clang as standalone recipe this also means that we can not bootstrap a native clang toolchain with libc++ as default runtime as it will cause circular dependencies.

A potential solution is to install clang toolchain with libc++ runtime on build host as pre-requisite and then use it to build llvm-native and configure llvm-native with -DLLVM_ENABLE_LIBCXX=ON

Another solution is to have a packageconfig option in rust to let it build its own
internal llvm if user chooses to do so.
Comment 1 Khem Raj 2025-10-21 17:48:11 UTC 
Here is ML discussion for more context - https://lists.openembedded.org/g/openembedded-core/topic/patch_v5_2_3_rust_use_llvm/115768136
Comment 2 Khem Raj 2025-10-22 04:46:57 UTC 
one way forward would be to let clang be allowed as host compiler going forward. That will cleanup clang-native.bbclass and clang.bbclass as well, where we do not have to specify additional dependencies and it will resemble gcc and gcc-native classes. Currently, we expect gcc toolchain to be pre-installed on build hosts and that reflects in this difference.

As a POC, I have the attached patch which can compile rust (bitbake rust) with clang and libc++ default host toolchain and TC_CXX_RUNTIME = "llvm"

Install pre-requisites ( ArchLinux )

sudo pacman -S --needed \
  llvm llvm-libs \
  clang lld lldb \
  compiler-rt libc++ libc++abi \
  openmp libclc

Fedora

sudo dnf install \
  llvm clang clang-tools-extra clang-analyzer \
  lld lldb \
  compiler-rt libomp \
  libcxx libcxxabi \
  libclc

Ubuntu/Debian

sudo apt update
sudo apt install \
  clang clang-tools \
  lld lldb \
  libomp-dev \
  libc++-dev libc++abi-dev \
  libclc-dev


Add PREFERRED_TOOLCHAIN_NATIVE = "clang" to config metadata
Comment 3 Khem Raj 2025-10-22 04:47:25 UTC 
Created attachment 5148 [details]
POC patch
Comment 4 Randy MacLeod 2026-06-04 15:25:40 UTC 
Sundeep, Can you look at this bug with the team an
decide if it's the same as another bug to track and fix how we build Rust?
Consult Khem as needed.