changes to master should be gated on tier-1 compilers building libcore correctly for the targets they support

[gnzlbg]

#62932 #62896 are regressions on tier-1 rustc nightly-x86_64-unknown-linux-gnu builds failing to build libcore for some of the targets that they are supposed to support cross-compiling to.

Changes to master should be gated on not introducing regressions here. Testing this is easy and takes very little CI time: once the toolchain has been build, just loop over all the targets that the rustc binary supports trying to build libcore with it. Building libcore for ~50 targets takes a couple of minutes.

The libc crate does that for stable and nightly toolchains here (build.sh). It might be possible to adapt that to rustc's CI.

Regressing on being able to build libcore for some target is not something that should land on beta, much less on stable Rust.

[cuviper]

Isn't that already tested by the fact that dist-* builders produce cross-compiled artifacts? I suppose that's only from an x86_64-linux host though, not all tier-1 hosts -- is this what you mean?

[cuviper]

I don't mean to discount the regressions you mention. I'm just pointing out that CI already does have some cross-compilation that would gate all branches. There may be some additional factor that affects those regressions differently, like the use of xargo.

[gnzlbg]

What I mean is that with a nightly-x86_64-unknown-linux-gnu rustc on a x86_64-unknown-linux HOST you can cross compile to dozens of targets, and for many targets the first step is building libcore for that target.

Isn't that already tested by the fact that dist-* builders produce cross-compiled artifacts?

No, because cross-compiled artifacts are not produced by each HOST for all possible TARGETS that can be cross-compiled to from that host.

I suppose that's only from an x86_64-linux host though, not all tier-1 hosts -- is this what you mean?

The dist builders that cross compile on the x86_64-linux hosts only cross compile artifacts for some of the supported TARGETS, e.g., the ones that ship a rust-std component via rustup. For all other targets AFAICT nothing is done, even though when building code for them the first thing that happens is that libcore must be built.

There may be some additional factor that affects those regressions differently, like the use of xargo.

What xargo does is build a sysroot for the target, starting by building libcore, and then if requested building liballoc, libstd, and its dependencies. The regressions mentioned occur because libcore fails to build. If libcore doesn't build, the target is pretty much useless.

[nikic]

The dist builders that cross compile on the x86_64-linux hosts only cross compile artifacts for some of the supported TARGETS, e.g., the ones that ship a rust-std component via rustup. For all other targets AFAICT nothing is done, even though when building code for them the first thing that happens is that libcore must be built.

rust-std is (afaik) not necessarily std, it can also just be core/alloc, and those are built for pretty much all targets, including the ones in the referenced issues. If you check the dist-various-1 build logs, there's a Building stage2 std artifacts (x86_64-unknown-linux-gnu -> thumbv6m-none-eabi) at some point, which in that case will only build core/alloc, not std, and later dist that.

[gnzlbg]

If that is the case, then I have no idea how those components have stopped to build.

[pnkfelix]

As far as I can tell this is a question for the infrastructure team. (If not, then I guess its T-compiler, but either way, it needs a team assigned.)

Nominating for prioritization.

[aidanhs]

So, I think there are two pieces here:

1. libcore fails to compile for thumbv6m-none-eabi #62932 relates to cross compiling using xargo - the only blessed way of building libcore is via x.py, which I believe is tested. Outside of that is generally best effort and subject to breakage
2. Segfault compiling libc on armv7-unknown-linux-gnueabihf #62896 relates to using an arm-host compiler to build libc (also doesn't mention libcore) - we don't test this compiler in CI because we don't have ARM hardware, so indeed it is subject to random bugs in LLVM

I don't think there's anything to do related to libcore on tier1 compilers left to do under this issue - let me know if I've got something wrong.

[gnzlbg]

Each Rust compiler is a cross-compiler. We do test, for some cross-compilers, that they are able to cross-compile to some targets, e.g. the Linux x86_64-unknown-linux-gnu compiles libcore, etc. for all targets for which we do ship these components with rustup.

AFAICT, we don't test that each cross-compiler can actually cross-compile to all the targets it support, e.g., we don't test anywhere that the i686-unknown-linux-gnu can cross-compile libcore for a powerpc64le-unknown-linux-gnu target, or that x86_64-unknown-linux-gnu can cross-compile libcore for those targets for which we do not ship libcore with rustup, but that the cross-compiler supports.