Date: Fri, 07 Jan 2022 13:25:56 +0100
To: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Thoughts on self-hosting compilers in Alpine
From: =?UTF-8?Q?S=C3=B6ren?= Tempel <soeren@soeren-tempel.net>
References: <33KG0XO61I4IL.2Z7RTAZ5J3SY6@8pit.net>
 <20211122135336.4f23002c@vostro> <25NDCA56CEJST.3KSBK3JLZFOCL@8pit.net>
 <20211125133127.639721c9@vostro>
In-Reply-To: <20211125133127.639721c9@vostro>
Message-Id: <2AFTQR1BCRUGG.3SMHH1I19MHLG@8pit.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

Little status update specifically on Go: I made some improvements to
gccgo in the past few weeks [1, 2, 3, 4, 5, 6]. With these changes
applied, it is now possible to bootstrap Google's Go implementation with
gccgo on all architectures supported by Alpine [7].

I also submitted a few of our libgo/gccgo related patches upstream in
order to improve gccgo's upstream musl support [8, 9, 10]. Ideally, I
would like to see all of our gccgo patches integrated upstream.

The only remaining problem I am presently aware of is that 32-bit
architectures seem to run out-of-memory on the CI when used with
multiple OS threads which execute user-level Go code simultaneously
(hence bootstrapped with GOMAXPROCS=3D1). Nonetheless, gccgo should now be
a viable option to bootstrap community/go if we want to go down this
path.

Greetings,
S=C3=B6ren

[1]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27772
[2]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27875
[3]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28185
[4]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28525
[5]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29185
[6]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29096
[7]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/27944
[8]: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587138.html
[9]: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585536.html
[10]: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587520.html

Timo Teras <timo.teras@iki.fi> wrote:
> On Wed, 24 Nov 2021 09:21:57 +0100
> S=C3=B6ren Tempel <soeren@soeren-tempel.net> wrote:
>=20
> > > I am not sure if it would be possible to bootstrap go with gcc-go?
> > > But there might exist also some other paths. =20
> >=20
> > Yes, that should be possible and that's exactly what I would like to
> > do for Go. I just haven't gotten around to fixing all the minor
> > issues with the gcc-go based bootstrap process yet.
>=20
> Cool!
>=20
> > > But as discussed in the thread, it seems each compiler has unique
> > > requirements on how to bootstrap it. Granted, this is getting
> > > painful as the number of self-dependent programming languages
> > > increase. And for some language full bootstrap just is not feasible
> > > which makes things quite annoying. =20
> >=20
> > Right, I would just like to make the bootstrap process transparent. So
> > for example, just by looking at community/go/APKBUILD it is entirely
> > unclear how Go was bootstrapped initially for the riscv64 or ppc64le
> > architecture.
>=20
> So community/go supports cross-building for bootstrapping. x86_64
> system was used to cross-build go for those target as go-bootstrap.
>=20
> I am not sure if the cross-built go has functional differences or not.
> But during first native build round go would then get rebuilt natively
> by the earlier cross-built compiler.
>=20
> This kind of cross-built bootstrapping is often used for new targets.
> And this is how e.g. gcc is bootstrapped for new systems too.
>=20
> Timo