Add ppc64, ppc64le, s390 host release builds for linux

[brson]

All three of these architectures are supported by Debian and Fedora (and RHEL). To make it easier for them to package Firefox it would be proper for us to have compilers for these architectures. End of year is a reasonable timeframe.

• s390
• ppc64
• ppc64le

cc @hsivonen @stransky @glandium @fabiand @sylvestre @infinity0

[infinity0]

Nice, thanks! Here are the pages describing supported architectures for Debian and Fedora.

You might also want to add mips64el to your list - Fedora already supports it, and it's due to be supported by Debian with the next stable release this November (and both of us call it mips64el, unlike the Fedora:pcc64le/Debian:ppc64el difference).

Also we both call it "s390x" for the newer 64bit chips.

[nagisa]

s390 corresponds to the SystemZ in LLVM, which we have no support for in rust (yet?).

[brson]

@infinity0 Today we have target builds for mips and mipsel, but I haven't considered it a priority to make host builds for them yet. With mips64el we don't even have target builds though. I will open seperate issues for the mipses: #36015

Frankly, the reason I've prioritized these three together, and highly, is because they are IBM platforms, important to RHEL. Having them ready in Fedora will make things go smoother for the next RHEL when it comes time to package Firefox.

[japaric]

@infinity0 Do you know what's the minimum/oldest glibc each port is expected to run against? rustc
is dynamically linked to glibc and we should pick a glibc to link to that's not newer than the
glibc installed in any of these ports.

This is what's need to be done for each target:

For mips and mipsel:

b) Try to cross compile rustc for this target (locally)
c) Fix any error that pops up during the bootstrap
d) Smoke test the produced rustc
e) Add a build slave for this target and start producing nightly releases

For ppc64 and ppc64le :

a) Get/build an appropriate C cross toolchain (gcc + glibc). By appropriate, I mean that the
toolchain's glibc should be old enough to support the oldest supported release of
Debian/Fedora/RHEL.

• do (b), (c), (d) and (e)

mips64 and s390x are more complicated because there are no built-in targets for these:

• Add a basic target definition to librustc_back/target
• Enable the corresponding backend when building LLVM
• Teach rust-lang/libc about these architectures
• do (a), (b), (c), (d) and (e)

I'm look into this and report back here (or in #36015); it may take a while though.

[infinity0]

@japaric I'm not too sure myself, but I would guess whatever version is listed here in ~3 months' time when stretch is finally released as Debian 9. Right now this is glibc 2.23. I'll try to find someone who knows this better than I. Fedora probably has something similar.

[japaric]

glibc 2.23

Great! That's what we are using in the build slaves (for ppc* and mips*) right now. If we find out later that we need an older version, we can always revisit.

[sylvestre]

FYI, LLVM 3.8 is supported correctly on Debian for these three archs: https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8

[japaric]

OK, I got a functional rustc for ppc64 and also managed to build rustc for ppc64el but couldn't test the latter under qemu because it segfaulted. But qemu-ppc64el segfaulted with every other binary I threw at it so ... yeah, perhaps that rustc also works but I have no way to know (I don't have powerpc hardware lying around).

I sent a PR (rust-lang-deprecated/rust-buildbot#121) with the required changes to the buildbot repository. Now it's @alexcrichton's turn to do the heavy work of spinning up more build slaves that will produce the rustcs for these targets.

I'll look into s390x next.

[japaric]

I'll look into s390x next.

#36028 adds initial support for s390x