-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustc deadlocks on FreeBSD #44433
Comments
Looks like we're using 10.2 on ci:
|
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more. |
So I'm kind of stuck because, when I try to test locally, I run into #43982 unless I remove |
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling |
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default… |
…ng#44433. The main goal here is to use FreeBSD's normal libc++, instead of statically linking the libstdc++ packaged with GCC, because that libstdc++ has bugs that cause rustc to deadlock inside LLVM. But the easiest way to use libc++ is to switch the build from GCC to Clang, and the Clang package in the Ubuntu image already knows how to cross-compile (given a sysroot and preferably cross-binutils), so the toolchain script now uses that instead of building a custom compiler. This also de-duplicates the `build-toolchain.sh` script.
…chton Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes rust-lang#44433. The main goal here is to use FreeBSD's normal libc++, instead of statically linking the libstdc++ packaged with GCC, because that libstdc++ has bugs that cause rustc to deadlock inside LLVM. But the easiest way to use libc++ is to switch the build from GCC to Clang, and the Clang package in the Ubuntu image already knows how to cross-compile (given a sysroot and preferably cross-binutils), so the toolchain script now uses that instead of building a custom compiler. This also de-duplicates the `build-toolchain.sh` script.
Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes #44433 Reviving #45077, from @jld: > The main goal here is to use FreeBSD's normal libc++, instead of > statically linking the libstdc++ packaged with GCC, because that > libstdc++ has bugs that cause rustc to deadlock inside LLVM. > > But the easiest way to use libc++ is to switch the build from GCC to > Clang, and the Clang package in the Ubuntu image already knows how to > cross-compile (given a sysroot and preferably cross-binutils), so the > toolchain script now uses that instead of building a custom compiler. > > This also de-duplicates the build-toolchain.sh script. #45077 was close but didn't quite make it. I rebased @jld's work off the current `master` and started with that. I was able to determine that this Travis error (#45077 (comment)) was ultimately caused by `src/librustc_llvm/build.rs` attempting to follow a wrong value in `LLVM_STATIC_STDCPP` (#45077 (comment)). I looked at the downstream port for FreeBSD (https://svnweb.freebsd.org/ports/head/lang/rust/) and it seems like they do not use `--enable-llvm-static-stdcpp`. Since `libc++` is included in the FreeBSD 10+ base system, we don't need to statically link it either? So in b989428 I have set the FreeBSD build to not actually use `LLVM_STATIC_STDCPP`. I was able to run `./src/ci/docker/run.sh` with both `dist-i686-freebsd` and `dist-x86_64-freebsd` successfully and in about 1 minute of testing it seemed like the dist-x86_64-freebsd results worked on a FreeBSD 11 system. It should fix #44433, which seems to be affecting many potential users. Also FreeBSD users should be able to `./x.py build` which should help anyone who wants to upstream fixes for FreeBSD. Questions: Does this approach seem to be the right way to go? Do we actually really want to statically link `libc++`? (I tried that here, but it ultimately ran into a roadblock on x86_64: #45077 (comment)) Can we rewrite the comment here to be more clear about why some systems aren't going to actually use this option: https://github.com/rust-lang/rust/blob/b989428f7dec7b52d68bed6a21e9b5b0a8086267/src/bootstrap/compile.rs#L550-L553 How does this affect users of older FreeBSD systems? It seemed like no one was complaining about using a 10.3 base version in the thread for #45077. FreeBSD seems to only officially support 10.3, 10.4, and 11.x right now, do we have to consider older users? The `libc++` stuff came in for FreeBSD 10, older FreeBSD used `libstdc++`. Looks like @alexcrichton was leading the discussion on the previous issue: r? @alexcrichton Let me know what I can do to help get this through.
Steps to reproduce, on my FreeBSD/amd64 11.0 system:
rustc --crate-type staticlib conftest.rs
, whereconftest.rs
is:It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as #36905: threads A and B are both in
LLVMRustWriteOutputFile
, thread A gets tollvm::X86InstrFMA3Info::initGroupsOnce
first andcall_once
s a lambda, then thread B entersllvm::X86InstrFMA3Info::initGroupsOnce
and blocks inpthread_once
with thestd::call_once
global mutex held, then thread A callsstd::call_once
reentrantly on a differentonce_flag
and deadlocks.But there might be a nicer solution than for #36905, because downstream has this patch:
FreeBSD switched to
libc++
in 10.0, on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the oldest supported release branch.libc++
appears to have a self-containedcall_once
that doesn't usepthread_once
, and emprically the Rust 1.18.0 package available viapkg install
doesn't deadlock.So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
The text was updated successfully, but these errors were encountered: