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/ci/docker/scripts | |
| 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/ci/docker/scripts')
| -rwxr-xr-x | src/ci/docker/scripts/freebsd-toolchain.sh | 103 |
1 files changed, 103 insertions, 0 deletions
diff --git a/src/ci/docker/scripts/freebsd-toolchain.sh b/src/ci/docker/scripts/freebsd-toolchain.sh new file mode 100755 index 00000000000..15ed318f8ce --- /dev/null +++ b/src/ci/docker/scripts/freebsd-toolchain.sh @@ -0,0 +1,103 @@ +#!/bin/bash +# Copyright 2016-2017 The Rust Project Developers. See the COPYRIGHT +# file at the top-level directory of this distribution and at +# http://rust-lang.org/COPYRIGHT. +# +# Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or +# http://www.apache.org/licenses/LICENSE-2.0> or the MIT license +# <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your +# option. This file may not be copied, modified, or distributed +# except according to those terms. + +set -eux + +arch=$1 +binutils_version=2.25.1 +freebsd_version=10.3 +triple=$arch-unknown-freebsd10 +sysroot=/usr/local/$triple + +hide_output() { + set +x + local on_err=" +echo ERROR: An error was encountered with the build. +cat /tmp/build.log +exit 1 +" + trap "$on_err" ERR + bash -c "while true; do sleep 30; echo \$(date) - building ...; done" & + local ping_loop_pid=$! + $@ &> /tmp/build.log + trap - ERR + kill $ping_loop_pid + set -x +} + +# First up, build binutils +mkdir binutils +cd binutils +curl https://ftp.gnu.org/gnu/binutils/binutils-${binutils_version}.tar.bz2 | tar xjf - +mkdir binutils-build +cd binutils-build +hide_output ../binutils-${binutils_version}/configure \ + --target="$triple" --with-sysroot="$sysroot" +hide_output make -j"$(getconf _NPROCESSORS_ONLN)" +hide_output make install +cd ../.. +rm -rf binutils + +# Next, download the FreeBSD libraries and header files +mkdir -p "$sysroot" +case $arch in + (x86_64) freebsd_arch=amd64 ;; + (i686) freebsd_arch=i386 ;; +esac + +files_to_extract=( +"./usr/include" +"./usr/lib/*crt*.o" +) +# Try to unpack only the libraries the build needs, to save space. +for lib in c cxxrt gcc_s m thr util; do + files_to_extract=("${files_to_extract[@]}" "./lib/lib${lib}.*" "./usr/lib/lib${lib}.*") +done +for lib in c++ c_nonshared compiler_rt execinfo gcc pthread rt ssp_nonshared; do + files_to_extract=("${files_to_extract[@]}" "./usr/lib/lib${lib}.*") +done + +URL=https://download.freebsd.org/ftp/releases/${freebsd_arch}/${freebsd_version}-RELEASE/base.txz +curl "$URL" | tar xJf - -C "$sysroot" --wildcards "${files_to_extract[@]}" + +# Fix up absolute symlinks from the system image. This can be removed +# for FreeBSD 11. (If there's an easy way to make them relative +# symlinks instead, feel free to change this.) +set +x +find "$sysroot" -type l | while read symlink_path; do + symlink_target=$(readlink "$symlink_path") + case $symlink_target in + (/*) + echo "Fixing symlink ${symlink_path} -> ${sysroot}${symlink_target}" >&2 + ln -nfs "${sysroot}${symlink_target}" "${symlink_path}" ;; + esac +done +set -x + +# Clang can do cross-builds out of the box, if we give it the right +# flags. (The local binutils seem to work, but they set the ELF +# header "OS/ABI" (EI_OSABI) field to SysV rather than FreeBSD, so +# there might be other problems.) +# +# The --target option is last because the cross-build of LLVM uses +# --target without an OS version ("-freebsd" vs. "-freebsd10"). This +# makes Clang default to libstdc++ (which no longer exists), and also +# controls other features, like GNU-style symbol table hashing and +# anything predicated on the version number in the __FreeBSD__ +# preprocessor macro. +for tool in clang clang++; do + tool_path=/usr/local/bin/${triple}-${tool} + cat > "$tool_path" <<EOF +#!/bin/sh +exec $tool --sysroot=$sysroot --prefix=${sysroot}/bin "\$@" --target=$triple +EOF + chmod +x "$tool_path" +done |
