Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes #44433. #45077
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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.
|
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
|
I've tested this locally, but only after removing I could try splitting out the toolchain script deduplication so the history is easier to follow, although I wound up rewriting most of it so I'm not sure how much that would help. |
|
📌 Commit 270c517 has been approved by |
carols10cents
added
the
S-waiting-on-bors
|
⌛ Testing commit 270c517 with merge 1079bd03418e3011e683fba6fe46fdee4851d17d... |
|
💔 Test failed - status-travis |
|
@bors retry
|
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Oct 11, 2017
…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.
|
The rollup #45207 failed to build Problematic command line: |
|
⌛ Testing commit 270c517 with merge 3878b454f953b7bf4c07b2a075147b8734baad16... |
|
💔 Test failed - status-travis |
kennytm
added
S-waiting-on-author
|
triage ping for @jld, looks like there may be some test failures! |
|
@bors r- |
|
Hi @jld, do you have time to look into this issue again and see why the CI cannot compile |
|
Thank you for your hard work in this PR, @jld! However, since we haven't heard from you in over 14 days, I'm going to go ahead and close this to keep things tidy. Please feel free to re-open it when you have some time to address the current issues with it! |
|
@jld: It seems this is still very close to working. By eliminating the blank The empty
In order to pass the build today, I just made that particular Looks like @alexcrichton wrote this section, maybe he can help point us to more information about
The reason it worked for you but not on CI can be found in 1080a69, I was tipped off by @alexcrichton here #46781 (comment) -- when the CI is run, (That flag probably also has something to do with your comment, here #43982 (comment), about needing to remove If you aren't interested in working on this anymore, I might try to pick it up and add on to your original commit with whatever other changes are needed to get this working. |
|
Hiding the previous version of the comment, me trying to find my way around:
> Looks like @alexcrichton wrote this section, maybe he can help point us to more information about LLVM_STATIC_STDCPP. Since the whole point here is to use libc++ instead of libstdc++, we'll probably need to modify something, somewhere....or ignore this line only in the case of FreeBSD, or something.
Looks like the Lines 550 to 557 in 7eb64b8 It's not quite clear whether the comment above considers FreeBSD to be "linux" or "not linux". I don't know enough to know why it would or wouldn't be supported. The blank So apparently during If we wanted a static stdcpp on FreeBSD with clang, (Do we? I don't know.), it would be named
Edit: Now I have a better idea what's going on. Okay, so I got far enough in debugging to find that: Lines 623 to 627 in 7eb64b8 Is going to return something like: When using the GNU compilers. But when target is So we want to send it to look for |
|
I think most of this path was wrong, hiding. I attempted the following change here: Lines 550 to 557 in 7eb64b8 This time Full output of error: I'm not quite sure where to go next. Edit: The diff above produced a successful build with |
bors
added a commit
that referenced
this pull request
Dec 26, 2017
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.shscript.