Update GCC to 11.2.0, align musl version with Rust

[messense]

bors: amd64

[messense]

bors try amd64 --target s390x-unknown-linux-musl

[bors[bot]]

try

Build succeeded:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

  = note: /usr/local/musl/bin/../lib/gcc/s390x-unknown-linux-musl/11.2.0/../../../../s390x-unknown-linux-musl/bin/ld: /usr/local/musl/bin/../lib/gcc/s390x-unknown-linux-musl/11.2.0/../../../../s390x-unknown-linux-musl/bin/ld: DWARF error: can't find .debug_ranges section.
          /home/rust/src/target/s390x-unknown-linux-musl/debug/deps/libopenssl_sys-70172c64409e3e90.rlib(curve448.o): in function `recode_wnaf':
          curve448.c:(.text.recode_wnaf+0xee): undefined reference to `__ctzdi2'
          /usr/local/musl/bin/../lib/gcc/s390x-unknown-linux-musl/11.2.0/../../../../s390x-unknown-linux-musl/bin/ld: read-only segment has dynamic relocations
          collect2: error: ld returned 1 exit status

DWARF error: can't find .debug_ranges section.

Interesting.

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build succeeded:

• conclusion

[messense]

bors try amd64

[bors[bot]]

try

Build failed:

• conclusion

[messense]

  = note: /usr/local/musl/bin/../lib/gcc/aarch64-unknown-linux-musl/11.2.0/../../../../aarch64-unknown-linux-musl/bin/ld: /root/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-musl/lib/libcompiler_builtins-413a2b918f1f8443.rlib(cpu_model.o): in function `init_have_lse_atomics':
          /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.73/./lib/builtins/cpu_model.c:811: undefined reference to `getauxval'
          collect2: error: ld returned 1 exit status

• https://github.com/rust-lang/rust/issues/76992#issuecomment-845636335
• https://github.com/rust-lang/rust/issues/89626

[messense]

bors retry

[bors[bot]]

try

Build succeeded:

• conclusion

[messense]

bors try arm64

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors try amd64 --target s390x-unknown-linux-musl

[bors[bot]]

try

Build succeeded:

• conclusion

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors try arm64

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors try amd64 --target aarch64-unknown-linux-musl

[bors[bot]]

try

Build succeeded:

• conclusion

[messense]

bors try armv7

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors try arm64 --target arm-unknown

[paulwratt]

on the last conclusion I see (only looked at the armv7 armv7 cross-build) is it possible to use an interim docker image, after this is completed.

I see the build takes 4+ hours, and unless I read the timing wrong, it would shave off 30 odd minutes. But is this an issue because Jammy is still being updated/patched atm? or would said interim docker image need to be updated due to more/less build requirement later on? (in which case my suggestion is moot)

[bors[bot]]

try

Build succeeded:

• conclusion

[messense]

bors try armv7 --target powerpc64le s390x

[messense]

@paulwratt IMO the bigest issue ATM is that GHA cache limit 10G is too little which causes lots of cache misses. I'm trying to switch to registry cache instead.

[paulwratt]

IMO the bigest issue ATM is that GHA cache limit 10G is too little which causes lots of cache misses. I'm trying to switch to registry cache instead.

Seems like you at least have a handle on the general problem. How differcult is that switch (similar to test+commit+recycle thats going on with bors builds atm?).

if someone was to build a set of base docker images suitable for your needs (so you would at least start with the musl-cross step) would you use them? (that would be to be at least at least amd/x86_64, aarch64 and armv7)

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors retry

[messense]

I see the build takes 4+ hours, and unless I read the timing wrong, it would shave off 30 odd minutes.

#8 216.8 Setting up llvm (1:14.0-55~exp2) ...
#8 216.8 Setting up llvm-14-dev (1:14.0.0-1ubuntu1) ...
#8 216.8 Setting up llvm-dev (1:14.0-55~exp2) ...
#8 216.8 Processing triggers for libc-bin (2.35-0ubuntu3.1) ...
#8 217.0 Processing triggers for ca-certificates (20211016) ...
#8 217.1 Updating certificates in /etc/ssl/certs...
#8 231.3 0 added, 0 removed; done.
#8 231.3 Running hooks in /etc/ca-certificates/update.d...
#8 231.3 done.
#8 DONE 232.0s

This step only takes around 4 minutes I think?

[paulwratt]

This step only takes around 4 minutes I think?

in which case I did read it wrong, that step I refered to was taking 28 seconds (not 28 minutes) nice that its come down anyways

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors try amd64 --target aarch64-unknown-linux-musl

[bors[bot]]

try

Build succeeded:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build succeeded:

• conclusion

[messense]

bors try armv7 --target powerpc64le s390x

[bors[bot]]

try

Build succeeded:

• conclusion

[messense]

bors r+

[bors[bot]]

Build succeeded:

• conclusion

[paulwratt]

(take the following "with a grain of salt")

nice job

from that list of builds (besides m68k-atari-mint-musl & m68k-unknown-linux-musl - thats why I'm here, to see if I can build these) the only other package missing is powerpc32be-musl (latest Asahi Linux and ?) and maybe x84_x32-musl (x32 is 32bit Intel userspace for 64bit Intel OS/CPU - as opposed to i386 or i686)

EDIT: (oh and the other reason I'm here) riscv64-musl

[messense]

If these targets have Rust support, feel free to open a PR to add them.

[paulwratt]

like I said with a grain of salt :)

that said, I am pretty sure Rust on riscv32 & riscv64 are already a thing. I also follow Rene Rebe who has a multi-arch build system (T2 SDE - support various LibC and various kernels), and I am sure I have seen him get Rust up and running on on PPC32BE and X32. But I cant verify these right at this moment.

(Also) like I said, I'm here to try and get a couple of different architectures (that are not on your list) to build musl cross build Rust, so I will definitely let you know how that goes (I'm looking at this as a test to get more musl and cross-musl on specific platforms after that). I just have to wait a bit longer before I can start doing that ..

(.. but with what you have just done here using Bors and the s390 PR, should make that task alot easier for me - and I've collected some invaluable info that makes fall-back approach simpler too)

(thanks for your patience)

[messense]

Here is the full list of supported musl libc targets from rustc

$ rustc +nightly --print target-list -Zunstable-options | grep musl
aarch64-unknown-linux-musl
arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armv5te-unknown-linux-musleabi
armv7-unknown-linux-musleabi
armv7-unknown-linux-musleabihf
hexagon-unknown-linux-musl
i586-unknown-linux-musl
i686-unknown-linux-musl
mips-unknown-linux-musl
mips64-openwrt-linux-musl
mips64-unknown-linux-muslabi64
mips64el-unknown-linux-muslabi64
mipsel-unknown-linux-musl
powerpc-unknown-linux-musl
powerpc64-unknown-linux-musl
powerpc64le-unknown-linux-musl
riscv32gc-unknown-linux-musl
riscv64gc-unknown-linux-musl
s390x-unknown-linux-musl
thumbv7neon-unknown-linux-musleabihf
x86_64-unknown-linux-musl