rustc deadlocks on FreeBSD

[jld]

Steps to reproduce, on my FreeBSD/amd64 11.0 system: rustc --crate-type staticlib conftest.rs, where conftest.rs is:

pub extern fn hello() { println!("Hello world"); }

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 to llvm::X86InstrFMA3Info::initGroupsOnce first and call_onces a lambda, then thread B enters llvm::X86InstrFMA3Info::initGroupsOnce and blocks in pthread_once with the std::call_once global mutex held, then thread A calls std::call_once reentrantly on a different once_flag and deadlocks.

But there might be a nicer solution than for #36905, because downstream has this patch:

--- src/librustc_llvm/build.rs.orig     2017-06-06 00:42:59 UTC
+++ src/librustc_llvm/build.rs
@@ -241,6 +241,8 @@ fn main() {
     let stdcppname = if target.contains("openbsd") {
         // OpenBSD has a particular C++ runtime library name
         "estdc++"
+    } else if target.contains("freebsd") {
+        "c++"
     } else if target.contains("netbsd") && llvm_static_stdcpp.is_some() {
         // NetBSD uses a separate library when relocation is required
         "stdc++_pic"

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-contained call_once that doesn't use pthread_once, and emprically the Rust 1.18.0 package available via pkg 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.

[mattico]

Looks like we're using 10.2 on ci:

rust/src/ci/docker/dist-i686-freebsd/build-toolchain.sh

Line 53 in dead08c

URL=ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/10.2-RELEASE/base.txz

[jld]

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.

[jld]

So I'm kind of stuck because, when I try to test locally, I run into #43982 unless I remove --enable-extended, which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.

[valpackett]

Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling libloading, but it usually succeeds after a couple tries. It's nearly always libloading!

[valpackett]

Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…