diff options
| author | bors <bors@rust-lang.org> | 2017-12-26 11:16:12 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2017-12-26 11:16:12 +0000 |
| commit | 0efdfa1d6220484770e3730062b92a9d2b2e20b9 (patch) | |
| tree | e73990ed6abba305ea2ab6255357facf4f124f01 /src/libstd/sys/cloudabi/stack_overflow.rs | |
| parent | 8cdde6db7138cf2365dd9ceb5b8814e92a922ed4 (diff) | |
| parent | b989428f7dec7b52d68bed6a21e9b5b0a8086267 (diff) | |
| download | rust-0efdfa1d6220484770e3730062b92a9d2b2e20b9.tar.gz rust-0efdfa1d6220484770e3730062b92a9d2b2e20b9.zip | |
Auto merge of #46941 - ScottAbbey:freebsd-build-update, r=alexcrichton
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 (https://github.com/rust-lang/rust/pull/45077#issuecomment-336029862) was ultimately caused by `src/librustc_llvm/build.rs` attempting to follow a wrong value in `LLVM_STATIC_STDCPP` (https://github.com/rust-lang/rust/pull/45077#issuecomment-352639456). 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 b989428f7dec7b52d68bed6a21e9b5b0a8086267 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: https://github.com/rust-lang/rust/pull/45077#issuecomment-353293414) 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.
Diffstat (limited to 'src/libstd/sys/cloudabi/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions
