I'm trying to build dev-lang/rust with clang and system-wide libcxx. Seems the issue fixed in https://bugs.gentoo.org/732632 is back: [rustc_llvm 0.0.0] cargo:rustc-link-lib=static=llvm-wrapper [rustc_llvm 0.0.0] cargo:rustc-link-search=native=/var/tmp/portage/dev-lang/rust-1.64.0-r1/work/rustc-1.64.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-0d080e9e638c9ba7/out [rustc_llvm 0.0.0] cargo:rerun-if-env-changed=LLVM_LINK_SHARED [rustc_llvm 0.0.0] cargo:rustc-link-lib=dylib=LLVM-14libcxx [rustc_llvm 0.0.0] thread 'main' panicked at 'assertion failed: !cxxflags.contains(\"stdlib=libc++\")', compiler/rustc_llvm/build.rs:348:13 [rustc_llvm 0.0.0] stack backtrace: [rustc_llvm 0.0.0] 0: rust_begin_unwind [rustc_llvm 0.0.0] 1: core::panicking::panic_fmt [rustc_llvm 0.0.0] 2: core::panicking::panic [rustc_llvm 0.0.0] 3: build_script_build::main [rustc_llvm 0.0.0] 4: core::ops::function::FnOnce::call_once [rustc_llvm 0.0.0] note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. [rustc_llvm 0.0.0] cargo:rustc-link-search=native=/usr/lib/llvm/14/lib64 [rustc_llvm 0.0.0] cargo:rerun-if-env-changed=LLVM_LINKER_FLAGS [rustc_llvm 0.0.0] cargo:rerun-if-env-changed=LLVM_STATIC_STDCPP [rustc_llvm 0.0.0] cargo:rerun-if-env-changed=LLVM_USE_LIBCXX error: failed to run custom build command for `rustc_llvm v0.0.0 (/var/tmp/portage/dev-lang/rust-1.64.0-r1/work/rustc-1.64.0-src/compiler/rustc_llvm)` I can reproduce this with the current version 1.64.0-r1 as well as with 1.63.0-r1 that I had previously successfully built, so I assume the recent changes to libcxx detection might cause the issue. Setting USE=-system-llvm leads to a successful build, but obviously cannot be the solution. Note that the backtrace quoted above points to llvm-14 for some reason - I have llvm-14 still installed since some packages still require it, but the main toolchain is llvm-15. So maybe the libcxx detection fails if llvm is installed in more than one slot? Reproducible: Always Steps to Reproduce: 1. Use system-wide clang and libcxx 2. Emerge dev-lang/rust 3. Profit Actual Results: Fails to compile due to libcxx detection somehow going wrong Expected Results: Should compile
Created attachment 823450 [details] emerge --info
Created attachment 823453 [details] build.log
Yeah, it's definitely not clocking it: ``` [target.x86_64-unknown-linux-gnu] ar = "llvm-ar" cc = "clang" cxx = "clang++" linker = "clang" ranlib = "llvm-ranlib" llvm-libunwind = "no" llvm-config = "/usr/lib/llvm/14/bin/llvm-config" ``` Could you poke at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/rust/rust-1.64.0-r1.ebuild#n361 & https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/rust/rust-1.64.0-r1.ebuild#n234 and look at why it's failing for you? I guess is_libcxx_linked returns no?
Your flags on sys-devel/clang and sys-devel/clang-common (all installed versions), plz.
(In reply to Manuel Nickschas from comment #0) > Note that the backtrace quoted above points to llvm-14 for some reason - I > have llvm-14 still installed since some packages still require it, but the > main toolchain is llvm-15. So maybe the libcxx detection fails if llvm is > installed in more than one slot? Rust forces LLVM 14, so if you use unversioned clang/clang++, it ends up using -14. If you want to force 15, try CC=clang-15 CXX=clang++-15.
Mystery has been solved. I got caught by the move of default-* USE flags from clang to clang-common, not realizing that simply renaming the entry in my config would affect the still-installed clang:14 which thus was indeed built with libstdcxx after world rebuild. And mgorny explained why clang:14 would be found, so this is also clarified. Sorry for the noise, I guess this can be closed (should I do this myself, or leave this to the assignee, in the general case?)
That said, I'm not sure if we should allow llvm.eclass to force older clang via CC/CXX. I could add some logic to prevent that from happening, like: if [[ ${CC} == *clang ]]; then local version=... if type -P ${CC}-${version} &>/dev/null; then CC+=-${version} fi fi
(In reply to Manuel Nickschas from comment #6) > Mystery has been solved. I got caught by the move of default-* USE flags > from clang to clang-common, not realizing that simply renaming the entry in > my config would affect the still-installed clang:14 which thus was indeed > built with libstdcxx after world rebuild. > > And mgorny explained why clang:14 would be found, so this is also clarified. > > Sorry for the noise, I guess this can be closed (should I do this myself, or > leave this to the assignee, in the general case?) It's OK to do it yourself if you think it's PEBKAC etc. (In reply to Michał Górny from comment #7) > That said, I'm not sure if we should allow llvm.eclass to force older clang > via CC/CXX. I could add some logic to prevent that from happening, like: > > if [[ ${CC} == *clang ]]; then > local version=... > if type -P ${CC}-${version} &>/dev/null; then > CC+=-${version} > fi > fi I think it might be worth considering this given firefox etc keeps reinventing it.
