Go 1.22 requires Go 1.20 or newer for bootstrapping. gccgo only
supports Go 1.18, therefore we cannot use it for bootstrapping
Go 1.22 directly and would need to package intermediate versions
of Go. Since our current packaging setup does not easily allow us
to maintain multiple versions of a package, and since it does not
seem likely that gccgo will support newer Go versions in the future,
this does not seam feasible.
Therefore, this commits abandons the much loved gccgo based bootstrap
and switches back to bootstrapping Go manually from an existing Alpine
installation using the bootstrap.sh script.
Fixes#15602
This reverts commit 3516e6e5e7.
they need updating prior to introducing a new architecture, otherwise
the attempt by bootstrap to pull in musl headers via musl-dev prior
to GCC stage 2 build will fail with a misleading error about a missing
directory
Previously, community/go depended on itself for compiler-bootstrapping
purposes. This approach has several issue which are were further
discussed on the ML some time ago [1]. By bootstrapping community/go
using gcc-go we can make the bootstrap path more transparent and also
ease bootstrapping new builder via bootstrap.sh as community/go no
longer needs to be cross-compiled from an existing Go installation.
As such, this commit also removes community/go from the bootstrap.sh.
There is nothing on the bootstrap path that depends on it, hence it
is fine that a bootstrapped/cross-compiled gcc doesn't have LANG_GO
support. Go was only added to bootstrap.sh previously in commit
f5c4b29891 due to the cross-compilation
requirement. This commit also removes the cross-compilation related
quirks from the Go APKBUILD.
I will further enhance the Go bootstrap setup by having both
community/go and gcc-go provide a virtual go-bootstrap package. Thereby
allowing compilation with either gcc-go or a prior community/go
installation.
[1]: https://lists.alpinelinux.org/~alpine/devel/%3C33KG0XO61I4IL.2Z7RTAZ5J3SY6%408pit.net%3E
/etc/apk/keys
cp: will not overwrite just-created '/home/buildozer/sysroot-aarch64/
/etc/apk/keys/buildozer-6086211a.rsa.pub' with '/home/buildozer/.
abuild/buildozer-6086211a.rsa.pub'
On some architectures rograms which use C11 or C++11 atomics,
like #include <atomic>, generally must link against -latomic
explicitly.
For now the check is only against riscv64, but the list may grow.
Signed-off-by: Roman Shaposhnik <rvs@zededa.com>
The list of packages doesn't change, but we need them build in a
different order because of changing dependencies.
Signed-off-by: Roman Shaposhnik <rvs@zededa.com>
When bootstrapping we need to have access to the freshly
minted abuild keys in the CBUILDROOT. While this can
potentially be done as a separate step it doesn't really
hurt to include it in the bootstrap.sh script.
Signed-off-by: Roman Shaposhnik <rvs@zededa.com>
Also don't bootstrap it in bootstrap.sh. Since we no longer use
the grsecurity patchset (which also provides PaX) and paxmark
was recently removed from all remaining packages, there should be
no need to bootstrap it early or include it in the images.
