Build the standard library for thumbv7neon-unknown-linux-gnueabihf in CI

[hsivonen]

Using the dist-armv7-linux image instead of dist-various-1 in order to use the ARMv7 toolchain available in dist-armv7-linux.

Closes #57030.

[rust-highfive]

r? @alexcrichton

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

[alexcrichton]

Thanks for the PR! Could this be added though to either dist-various-1 or dist-various-2? Those are in general our containers for building lots of assorted standard libraries.

[hsivonen]

As noted on the issue, this container already has the closest C toolchain match. Since the toolchain part is more complicated than the Python invocation to build the standard library, it seems bad to duplicate the toolchain across containers.

[alexcrichton]

Unfortunately the dist-armv7-linux container already takes almost all of it's allocated time (1h50m vs 2h). The dist-various-2 container, however, only takes 1h15m, so to ensure CI stays in a reasonable amount of time we need to add it to one of the -various- containers. The toolchain config can be shared/copied around between the containers.

[hsivonen]

If I try to merge the toolchain stuff from dist-armv7-linux into dist-various-2, as seen in this gist, the part where crosstool-ng builds stuff fails with:

In file included from zconf.tab.c:212:0:
zconf.hash.c:167:1: error: conflicting types for 'kconf_id_lookup'
 kconf_id_lookup (register const char *str, register size_t len)
 ^~~~~~~~~~~~~~~
zconf.hash.c:34:31: note: previous declaration of 'kconf_id_lookup' was here
 static const struct kconf_id *kconf_id_lookup(register const char *str, register unsigned int len);
                               ^~~~~~~~~~~~~~~
make[2]: *** [zconf.tab.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [build-lib-kconfig] Error 2
make: *** [build] Error 2

I'm guessing that the toolchain build conflicts with some of the other toolchains in dist-various-2.

Would it be acceptable to create a new container that is a copy of the changeset from this PR with the armv7-unknown-linux-gnueabihf build step removed?

[alexcrichton]

Unfortunately a new container means a new CI builder which we don't have resources for.

We don't really have any C code of substance in the standard library, though, so is the latest-and-greatest toolchain needed? As long as whatever's in the container has bare-bones support for the target it should be sufficient to produce binaries.

[hsivonen]

The force-pushed update adds the thumbv7neon-unknown-linux-gnueabihf standard library build to dist-various-1. I used dist-various-1, because it already had the toolchain, so the change doesn't add toolchain installation time to the overall duration of the CI run.

[alexcrichton]

@bors: r+

Great!

[bors]

📌 Commit 7dbb70e has been approved by alexcrichton

[bors]

⌛ Testing commit 7dbb70e with merge 106b3e9...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: alexcrichton
Pushing 106b3e9 to master...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: alexcrichton
Pushing 106b3e9 to master...

[hsivonen]

Thanks for the review/approval!

It looks like this missed the beta train by a little. Any chance of uplifting this to beta so that the Android and glibc targets could make it to the same stable release?

[alexcrichton]

I can nominate it for you, yes

[hsivonen]

Thanks!