go: add a binary bootstrap package (1.12 series for now) and switch the compiler to it from 1.4

[q66]

This adds a go1.12-bootstrap package newly used instead of go1.4-bootstrap to bootstrap the main Go compiler. The reason for this is to allow bootstrapping on platforms the ancient codebase does not support, particularly ppc64le and aarch64.

The new bootstrap package can technically run on all the targets that are in the intersection of what the official compiler supports and what Void supports.

There is a problem that the official binaries require glibc (just its dynamic linker, the libc itself and libpthread). In order to deal with that on musl, fetch a binary copy of glibc from Debian (which is reproducibly built, so it should be trustable) and patch the official binaries so that they use the newly bundled libc and dynamic linker. This allows the compiler to execute in a musl system, and build the proper target compiler (which will use the musl dynamic linker and libc, of course).

I chose the approach after evaluating all other choices, including gcompat and gccgo; in the end this was the only thing that truly and reliably worked.

I used gcompat to be able to run the compiler. In order for that to work, gcompat needs to be updated and patched, as in #16320. We still need to use patchelf to patch out the lib64 requirement.

The second part of this patchset switches the go package to use the new 1.12 bootstrap. Since 1.12, GOCACHE must be not set when bootstrapping, so that line was removed. I also added new broken lines to disable the package on big endian PowerPC systems (ppc64 BE support uses incorrect ABI and requires POWER8 hardware, making it not safely distributable; 32-bit ppc was just never supported at all).

Additionally, I also added a broken when cross-building on the same architecture to a different libc (e.g. x86_64 to x86_64-musl). This is because the build system does not account for this scenario and just does not cross build; this creates a package without failing but the contained compiler is just a compiler for the host system and will not function on the target. So at least until this problem is taken care of, disable it in order to not silently build broken packages.

If this is accepted, we can drop the go1.4-bootstrap package afterwards.

@the-maldridge @nilium

[q66]

Looks like something is wrong on the musl hosts; I will have to look into that - also the i686 fails in a strange way (on glibc)

[q66]

I think I might be able to ditch the glibc dependency entirely, by just patching stuff to use musl's dynlinker and libraries. This works on x86_64 but it's failing on ppc64le exactly the same as if trying to use gcompat. Gonna investigate more

[q66]

Updated to use gcompat, which works after some updates. But CI is on hold until #16320 is merged, which is on hold until #16325 is merged.

[q66]

All prerequisites merged; giving this another CI run.

[nilium]

Mentioned on IRC but forgot to put a comment here. Pretty sure this is the right way to go for compatibility with ppc and any future architectures that are added in given that Go 1.4 does not have the same support for various architectures as recent releases. Assuming gcompat is fully working, I don’t see any issues (outside of the existing i686 container issue, which isn’t related to these changes).

[q66]

Yeah, seems to be working alright. Go does not really need much in terms of C symbols so using gcompat for this is pretty easy.