rustbuild: Fix cross compiling to FreeBSD

[alexcrichton]

This commit fixes our support for cross compiling a compiler to run on FreeBSD.
Over the weekend I managed to get a cross compiler from Linux to FreeBSD 1
which I hope to soon use to start producing FreeBSD nightly compilers. With the
make dist support added in #32237 we should be able to produce standard
rustc/rust-std packages for FreeBSD through a new slave with this cross compiler.

Currently, however, we don't "Just Work" when cross compiling FreeBSD and a
number of changes were required (part of this PR). They include:

• A few build fixes were needed in LLVM. Our own branch has been rebased on the
  actual 3.8 release and I applied one extra commit 2 which contains two fixes:
  1. The LLVM CMake build system passes the -Wl,-z,defs flag on many
     platforms, but not when CMAKE_SYSTEM_NAME is "FreeBSD". Unfortunately
     this doesn't take into account when we're cross compiling, and as predicted
     the build will fail if -Wl,-z,defs is passed (see 3 for more info). To
     fix this we test TARGET_TRIPLE instead of the CMAKE_SYSTEM_NAME which
     is what we're compiling for which fixes the problem.
  2. The PATH_MAX constant is apparently defined in a different location than
     many other Unix systems, so a file which required this just needed some
     help to keep compiling.
• Support for compiling compiler-rt with CMake has been added to rustbuild. It
  looks like it just emulates Linux in what it compiles as it didn't seem to
  naturally produce anything else... At least the architecture is right, so
  seems good for now at least!

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

cc @dhuseby

I hope to soon set up FreeBSD nightlies after this lands (assuming it all continues to keep working), and perhaps soon after use the groundwork to tackle OpenBSD next! (cc @semarie)

[brson]

@bors r+

[bors]

📌 Commit 155735a has been approved by brson

[bors]

⌛️ Testing commit 155735a with merge 483fc71...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

[dhuseby]

@alexcrichton this is great! will this allow me to take the FreeBSD buildbot down once it is in place and working?

[alexcrichton]

@dhuseby it's up to you I think. We're not producing FreeBSD nightlies and standard libraries (as of yesterday), but we're unfortunately not running any tests just yet. If you want to keep the bots online to run tests we can do that, but for nightlies we'll at least have that taken care of

[dhuseby]

@alexcrichton so this is building nightlies and snapshots? what about cargo nightlies and snapshots?

[alexcrichton]

Yeah we've got FreeBSD nightlies (not snapshots) for both rustc and Cargo now

[dhuseby]

@alexcrichton so do these show up in the buildbot builders lists? if we have these for linux/windows/mac, why do we still have buildbots for those platforms?

[alexcrichton]

Yeah the auto-linux-64-x-freebsd and auto-linux-64-x-netbsd builders are the auto builders, and the nightly-dist-rustc-cross-linux is just one massive builder creating a mess of compilers.

I left the other FreeBSD bots for now because the cross-compiled ones aren't running tests (whereas the current ones are), but if you'd like I can turn those off.

[dhuseby]

@alexcrichton so what is it going to take to get them to start running tests?

[dhuseby]

@alexcrichton I suppose that's not possible unless we have a machine running freebsd right?

[alexcrichton]

Yeah we don't have any time frame for getting a FreeBSD bot, but we could in theory also run them under qemu somehow (or some subset). Either way that's pretty far out and not currently planned.

[dhuseby]

@alexcrichton i've been interested in figuring out how to make gitian work with the bsd OS's just like it does with Linux now. Currently, it relies on qemu to boot a linux image, install dependencies, clone the code, run a build, and extract the build outputs. If we could make it also drive qemu to boot a bsd image, install dependencies, clone the code, run a build, and extract the build outputs, we could get away from cross-compiling from Linux.

What do you think?

[alexcrichton]

Hey so long as it works and id easy to manage I'm game :).

I've had bad luck with performance in the past running code in qemu (took forever to finish), but maybe I was passing the wrong options or there's some optimizations along the way?

[dhuseby]

@alexcrichton All of my buildbot slaves are run as qemu vm's (with kvm acceleration) on my server. It seems to run fine.

[alexcrichton]

Interesting! Seems like we should definitely at least try to get these running!