about summary refs log tree commit diff
path: root/src/libstd/sys/cloudabi/stack_overflow.rs
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2017-12-26 11:16:12 +0000
committerbors <bors@rust-lang.org>2017-12-26 11:16:12 +0000
commit0efdfa1d6220484770e3730062b92a9d2b2e20b9 (patch)
treee73990ed6abba305ea2ab6255357facf4f124f01 /src/libstd/sys/cloudabi/stack_overflow.rs
parent8cdde6db7138cf2365dd9ceb5b8814e92a922ed4 (diff)
parentb989428f7dec7b52d68bed6a21e9b5b0a8086267 (diff)
downloadrust-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