Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 732632 - dev-lang/rust does not build when using libcxx as stdlib
Summary: dev-lang/rust does not build when using libcxx as stdlib
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Georgy Yakovlev
URL:
Whiteboard:
Keywords:
: 747976 (view as bug list)
Depends on:
Blocks: systemwide-libcxx
  Show dependency tree
 
Reported: 2020-07-14 21:07 UTC by Jeffrey Lin
Modified: 2022-06-01 09:15 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (rust-1.44.1:20200711-032546.log,938.45 KB, text/x-log)
2020-07-14 21:07 UTC, Jeffrey Lin
Details
libcxx rust failing to bootstrap itself (rust-1.44.1:20200715-030153.log,4.93 KB, text/x-log)
2020-07-15 16:52 UTC, Jeffrey Lin
Details
1.61.0 with "use-libcxx = true" in config.toml (build.log.xz,78.80 KB, application/x-xz)
2022-05-25 16:35 UTC, Manuel Nickschas
Details
build.log for 1.61.0-r1 (build.log.xz,79.13 KB, application/x-xz)
2022-05-25 23:23 UTC, Manuel Nickschas
Details
emerge --info when trrying to build 1.61.0-r1 (emerge.info,18.39 KB, text/plain)
2022-05-25 23:24 UTC, Manuel Nickschas
Details
build.log for 1.61.0-r1 with use-libcxx=true (build.log.xz,79.42 KB, application/x-xz)
2022-05-27 07:12 UTC, Manuel Nickschas
Details
build.log with USE=-system-llvm (build.log.xz,147.35 KB, application/x-xz)
2022-05-27 09:43 UTC, Manuel Nickschas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey Lin 2020-07-14 21:07:05 UTC
Created attachment 649226 [details]
build.log

The solution is to add in config.toml under the [llvm] section:

use-libcxx = true

when the compiler is sys-devel/clang[default-libcxx] or -stdlib=libc++ is passed as a compiler flag.

Arfrever suggested the following check on IRC:

tc-is-clang && { has_version "sys-devel/clang:$(clang-major-version)[default-libcxx]" || is-flagq -stdlib=libc++; }
Comment 1 Georgy Yakovlev archtester gentoo-dev 2020-07-14 21:22:51 UTC
yes, please go with that suggestion.

I don't like it because it introduces a automagic dependency, but amount of users who's going to use it will be less than 5 probably, so that's fine ;-)


as for implementation, please pass ( we are not doing it now)

use-libcxx = false
in [llvm] section by default, in the main `echo` call.
and after that call introduce a check and a sed that will modify

something like
> if need-to-use-libcxx-check; then 
> sed -i '/^use-libcxx/ s/false/true/' config.toml || die
> fi
Comment 2 Jeffrey Lin 2020-07-15 16:52:27 UTC
Created attachment 649312 [details]
libcxx rust failing to bootstrap itself

I'm having trouble getting rust to compile itself with USE=system-bootstrap after compiling successfully with libcxx.  Attached is the build.log showing the failure.  It references a failed command, here is the output of the command run:

# /usr/bin/cargo build --manifest-path /tmp/portage/dev-lang/rust-1.44.1/work/rustc-1.44.1-src/src/bootstrap/Cargo.toml --verbose --locked --frozen
error: failed to get `cc` as a dependency of package `bootstrap v0.0.0 (/tmp/portage/dev-lang/rust-1.44.1/work/rustc-1.44.1-src/src/bootstrap)`

Caused by:
  attempting to make an HTTP request, but --frozen was specified


When run without --frozen, the build system contacts crates.io.
Comment 3 12101111 2020-10-14 03:45:09 UTC
*** Bug 747976 has been marked as a duplicate of this bug. ***
Comment 4 12101111 2020-10-14 07:26:42 UTC
I compile rust 1.47.0 with `use-libcxx=true`, system-bootstrap and system-llvm and it can bootstrap itself.

I can drop this hack:

> cat /usr/lib/libstdc++.so
GROUP ( libc++_shared.so libc++abi.so libunwind.so )
Comment 5 Manuel Nickschas 2022-05-25 16:35:42 UTC
Created attachment 780782 [details]
1.61.0 with "use-libcxx = true" in config.toml

Any news on this one? I had everything building against libc++ (even without any patches) with rust-1.60.0, but 1.61.0 broke my build and I can't seem to be able to fix it. Adding "use-libcxx = true" to config.toml does not seem to work for me either (see attached build.log). I am at a loss as to how to fix this now...
Comment 6 tt_1 2022-05-25 16:54:32 UTC
If rust got broken for your specific usecase inbetween two stable versions, you do have a good chance to get enough evidence together to open an upstream bug. 

You could for instance start by diffing the released tarballs for the specific lib that fails to compile.
Comment 7 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-05-25 18:06:26 UTC
A fresh build.log and emerge --info in addition to the above suggestion would help too.
Comment 8 Manuel Nickschas 2022-05-25 23:23:27 UTC
build.log for 1.61.0 with the addition of "use-libcxx = true" in the part of the ebuild that writes config.toml was already attached to my previous comment. emerge info and a build.log for unmodified 1.61.0-r1 follow.

I know next to nothing about Rust, its deployment and how to debug these things, so reporting a proper upstream bug would probably not be the easiest thing for me...
Comment 9 Manuel Nickschas 2022-05-25 23:23:56 UTC
Created attachment 780794 [details]
build.log for 1.61.0-r1
Comment 10 Manuel Nickschas 2022-05-25 23:24:20 UTC
Created attachment 780797 [details]
emerge --info when trrying to build 1.61.0-r1
Comment 11 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-05-25 23:39:41 UTC
(In reply to Manuel Nickschas from comment #8)
> build.log for 1.61.0 with the addition of "use-libcxx = true" in the part of
> the ebuild that writes config.toml was already attached to my previous
> comment. emerge info and a build.log for unmodified 1.61.0-r1 follow.
> 
> I know next to nothing about Rust, its deployment and how to debug these
> things, so reporting a proper upstream bug would probably not be the easiest
> thing for me...

[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:351: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
[0m[0m[1m[31merror[0m[1m:[0m failed to run custom build command for `rustc_llvm v0.0.0 (/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/compiler/rustc_llvm)`

Caused by:
  process didn't exit successfully: `/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/release/build/rustc_llvm-179873ca4957ca7c/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=RUST_CHECK

Very odd. It's dying specifically because it's in your flags. I wonder what we need to pass down.
Comment 12 Georgy Yakovlev archtester gentoo-dev 2022-05-26 20:55:40 UTC
it happens here:

https://github.com/rust-lang/rust/blob/fe5b13d681f25ee6474be29d748c65adcd91f69e/compiler/rustc_llvm/build.rs#L351

> assert!(!cxxflags.contains("stdlib=libc++"));



so it runs llvm-config and checks if it cxxflags contain libc++


what does this command print on your system?

llvm-config --cxxflags

?
Comment 13 Georgy Yakovlev archtester gentoo-dev 2022-05-26 20:59:34 UTC
also what happens if you dont't use system-llvm? (you still will need use-libcxx though)
Comment 14 Georgy Yakovlev archtester gentoo-dev 2022-05-26 21:05:32 UTC
actually I don't thing your use-libcxx part works

here's part of config from your build log


 * config.toml contents:
changelog-seen = 2
[llvm]
download-ci-llvm = false
optimize = true
release-debuginfo = false
assertions = false
ninja = true
targets = "BPF;NVPTX;X86"
experimental-targets = ""
link-shared = true

[build]
...



so use-libcxx ls clearly missing from [llvm] section.
Comment 15 Larry the Git Cow gentoo-dev 2022-05-26 21:45:10 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3bdbb08f39ee8ad706760eca5138470e88722510

commit 3bdbb08f39ee8ad706760eca5138470e88722510
Author:     Georgy Yakovlev <gyakovlev@gentoo.org>
AuthorDate: 2022-05-26 21:44:04 +0000
Commit:     Georgy Yakovlev <gyakovlev@gentoo.org>
CommitDate: 2022-05-26 21:44:43 +0000

    dev-lang/rust: attempt to support libcxx in 1.61.0-r1
    
    Bug: https://bugs.gentoo.org/732632
    Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>

 dev-lang/rust/rust-1.61.0-r1.ebuild | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)
Comment 16 Georgy Yakovlev archtester gentoo-dev 2022-05-26 21:45:41 UTC
ok I comitted minor change, it should detect if you run libcxx

can you try it?
you should no longer need to edit the ebuild


I don't have libcxx setup, but configure properly sets 'use-libcxx = true' if I run

> CXX=clang CC=clang CXXFLAGS="-stdlib=libc++" ebuild rust-1.61.0-r1.ebuild clean configure
Comment 17 tt_1 2022-05-27 06:02:29 UTC
so libcxx is used if the detexed compiler is clang with USE="+system-libcxx", or if  -stdlib=libc++ is detected?
Comment 18 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-05-27 06:03:50 UTC
(In reply to tt_1 from comment #17)
> so libcxx is used if the detexed compiler is clang with
> USE="+system-libcxx", or if  -stdlib=libc++ is detected?

You read correctly - both are functionally the same, right? What's the issue?
Comment 19 Manuel Nickschas 2022-05-27 07:12:12 UTC
Created attachment 780989 [details]
build.log for 1.61.0-r1 with use-libcxx=true

Build log in #c5 was with an ebuild to include "use-libcxx=true". Build log in #c9 was without. Sorry for the confusion.

I tried again with your change, the flag is set correctly, but the build still fails for the same reason. To me it looks as if some component doesn't get the message that we're building with libcxx, and asserts because we do. FWIW, I don't even have -stdlib=libc++ in my CXXFLAGS, I build clang with USE="+system-libcxx" so it's the default. Something in the Rust build system seems to be figuring that out, and sets the -stdlib flag explicitly for some reason...

I'll try with USE=-system-llvm next, but I'm almost sure I already tried that before to no avail.

Thanks!
Comment 20 Manuel Nickschas 2022-05-27 09:43:43 UTC
Created attachment 781073 [details]
build.log with USE=-system-llvm

With USE=-system-llvm, I get a different error:

     Running `CARGO=/usr/lib/rust/1.60.0/bin/cargo CARGO_CRATE_NAME=rustc_llvm CARGO_MANIFEST_DIR=/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/compiler/rustc_llvm CARGO_PKG_AUTHORS='' CARGO_PKG_DESCRIPTION='' CARGO_PKG_HOMEPAGE
='' CARGO_PKG_LICENSE='' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=rustc_llvm CARGO_PKG_REPOSITORY='' CARGO_PKG_VERSION=0.0.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=0 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='
/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps:/usr/lib/rust/1.60.0/lib' OUT_DIR=/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-g
nu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-5d034262ce529127/out /var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/bootstrap/debug/rustc --crate-name rustc_llvm --edition=2021 compiler/rustc_llvm/src/lib.
rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C debuginfo=0 -C metadata=2e490da81da22c4b -C extra-filename=-2e490da81da22c4b --
out-dir /var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -C linker=clang -L dependency=/var/tmp/portage/dev-lang/ru
st-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps -L dependency=/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/release
/deps --extern libc=/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/liblibc-06fb9222ffad2320.rmeta --cfg=bootstrap -Csymbol-mangling-version=v0 -Zma
cro-backtrace -Ztls-model=initial-exec -Zunstable-options '-Wrustc::internal' -Cprefer-dynamic -Z binary-dep-depinfo -L native=/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unkn
own-linux-gnu/release/build/rustc_llvm-5d034262ce529127/out -L native=/var/tmp/portage/dev-lang/rust-1.61.0-r1/work/rustc-1.61.0-src/build/x86_64-unknown-linux-gnu/llvm/build/lib -L native=/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0 --cfg 'llvm_comp
onent="asmparser"' --cfg 'llvm_component="bitreader"' --cfg 'llvm_component="bitwriter"' --cfg 'llvm_component="bpf"' --cfg 'llvm_component="coverage"' --cfg 'llvm_component="instrumentation"' --cfg 'llvm_component="ipo"' --cfg 'llvm_component="
linker"' --cfg 'llvm_component="lto"' --cfg 'llvm_component="nvptx"' --cfg 'llvm_component="x86"' -l static=llvm-wrapper -l static=LLVMX86TargetMCA -l static=LLVMMCA -l static=LLVMX86Disassembler -l static=LLVMX86AsmParser -l static=LLVMX86CodeG
en -l static=LLVMCFGuard -l static=LLVMGlobalISel -l static=LLVMX86Desc -l static=LLVMX86Info -l static=LLVMNVPTXCodeGen -l static=LLVMNVPTXDesc -l static=LLVMNVPTXInfo -l static=LLVMLTO -l static=LLVMPasses -l static=LLVMCoroutines -l static=LL
VMObjCARCOpts -l static=LLVMExtensions -l static=LLVMCoverage -l static=LLVMBPFDisassembler -l static=LLVMMCDisassembler -l static=LLVMBPFAsmParser -l static=LLVMBPFCodeGen -l static=LLVMSelectionDAG -l static=LLVMipo -l static=LLVMInstrumentati
on -l static=LLVMVectorize -l static=LLVMLinker -l static=LLVMIRReader -l static=LLVMFrontendOpenMP -l static=LLVMBPFDesc -l static=LLVMBPFInfo -l static=LLVMAsmPrinter -l static=LLVMDebugInfoMSF -l static=LLVMCodeGen -l static=LLVMTarget -l sta
tic=LLVMScalarOpts -l static=LLVMInstCombine -l static=LLVMAggressiveInstCombine -l static=LLVMTransformUtils -l static=LLVMBitWriter -l static=LLVMAnalysis -l static=LLVMProfileData -l static=LLVMDebugInfoDWARF -l static=LLVMObject -l static=LL
VMTextAPI -l static=LLVMMCParser -l static=LLVMMC -l static=LLVMDebugInfoCodeView -l static=LLVMBitReader -l static=LLVMAsmParser -l static=LLVMCore -l static=LLVMRemarks -l static=LLVMBitstreamReader -l static=LLVMBinaryFormat -l static=LLVMSupport -l static=LLVMDemangle -l dylib=rt -l dylib=dl -l dylib=m -l dylib=z -l static=c++`
error: could not find native static library `c++`, perhaps an -L flag is missing?

FWIW, I have sys-libs/libcxx built with USE=static-libs and /usr/lib64/libc++.a is available. So I guess this is a sandboxed build of the bundled toolchain, and again some part of the build system does not know about libcxx...
Comment 21 Georgy Yakovlev archtester gentoo-dev 2022-05-27 15:14:35 UTC
what's the output of

> llvm-config --cxxflags


on your system?
Comment 22 Manuel Nickschas 2022-05-29 19:59:07 UTC
# llvm-config --cxxflags
-I/usr/lib/llvm/14/include -std=c++14 -stdlib=libc++   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

Okay, so that's where the flag comes from apparently...
Comment 23 Jonas Rakebrandt 2022-05-30 11:19:53 UTC
After some testing and trying to understand the rust's build system I think I found the reason why rust fails to build with libcxx:

The config defaults the option `static-libstdcpp` in the `[llvm]` section to true because it isn't set by the ebuild. However this doesn't work because we build with libcxx.
This causes the error/panic in the 
`> assert!(!cxxflags.contains("stdlib=libc++"));` 
part so the build fails because we have `-stdlib=libc++` in our CXXFLAGS while trying to statically link against libstdc++.

The solution is to set `static-libstdcpp = false` if we are building with libcxx.

I just ran an emerge with this set in the config.toml to check and it built successfully against libcxx.
Comment 24 Manuel Nickschas 2022-05-30 20:49:23 UTC
I can confirm that Jonas' fix works for me as well! Thanks for pinpointing that.
Comment 25 Georgy Yakovlev archtester gentoo-dev 2022-05-31 17:31:38 UTC
Thanks for figuring it out, I don’t have the setup and it was weird figuring this out blindly, I’ll add this knob to libcxx condition block.
Comment 26 Larry the Git Cow gentoo-dev 2022-05-31 17:45:22 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1eec1bfb2d551241c3d4e67ecacf2f0c89e76632

commit 1eec1bfb2d551241c3d4e67ecacf2f0c89e76632
Author:     Georgy Yakovlev <gyakovlev@gentoo.org>
AuthorDate: 2022-05-31 17:42:51 +0000
Commit:     Georgy Yakovlev <gyakovlev@gentoo.org>
CommitDate: 2022-05-31 17:43:50 +0000

    dev-lang/rust: pass static-libstdcpp = false for libcxx build
    
    Bug: https://bugs.gentoo.org/732632
    Thanks-to: Jonas Rakebrandt <xarblu@protonmail.com>
    Tested-by: Manuel Nickschas <sputnick@quassel-irc.org>
    Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org>

 dev-lang/rust/rust-1.61.0-r1.ebuild | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
Comment 27 Manuel Nickschas 2022-06-01 09:15:35 UTC
Fixed ebuild confirmed working, thanks a lot to all involved!