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.
Steps to reproduce, on my FreeBSD/amd64 11.0 system:
rustc --crate-type staticlib conftest.rs, whereconftest.rsis: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::initGroupsOncefirst andcall_onces a lambda, then thread B entersllvm::X86InstrFMA3Info::initGroupsOnceand blocks inpthread_oncewith thestd::call_onceglobal mutex held, then thread A callsstd::call_oncereentrantly on a differentonce_flagand 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_oncethat doesn't usepthread_once, and emprically the Rust 1.18.0 package available viapkg installdoesn't deadlock.So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.