Re: i386 baseline issue for Go packages in Bookworm
On Sun, Apr 18, 2021 at 1:09 AM Shengjing Zhu wrote: > > Hi, > > As the release of Go 1.16, upstream no longer supports x87-only > floating-point. > > https://golang.org/doc/go1.16#386 > > > require at least SSE2 support on 386, raising Go's minimum GOARCH=386 > > requirement to the Intel Pentium 4 (released in 2000) or > > AMD Opteron/Athlon 64 (released in 2003). > > So we have 3 options for Go packages on i386 in Bookwarm. > > 1. Raise the i386 baseline to SSE2. > 2. Downgrade the Go packages to softfloat. > 3. Build all Go packages with GCCGO on i386. > > As for the option 3, I don't how best is supported by upstream. > But most packages may work, if some specific packages FTBFS after switching > to GCCGO, they need to be removed on i386 unfortunately. > An update on this issue. golang-1.16/1.16.3-4 has been uploaded to unstable. It's built with GO386=softfloat on i386 arch only. Which means any Go packages built with it on i386 will default to softfloat. But people try to cross build Go packages for i386, defaults to sse2. The settings can be checked by running `GOARCH=386 go env GO386`. And can be changed by setting GO386 env manually. -- Shengjing Zhu
Re: i386 baseline issue for Go packages in Bookworm
On 4/17/21 7:09 PM, Shengjing Zhu wrote: > Hi, > > As the release of Go 1.16, upstream no longer supports x87-only > floating-point. > > https://golang.org/doc/go1.16#386 > >> require at least SSE2 support on 386, raising Go's minimum GOARCH=386 >> requirement to the Intel Pentium 4 (released in 2000) or >> AMD Opteron/Athlon 64 (released in 2003). > > So we have 3 options for Go packages on i386 in Bookwarm. > > 1. Raise the i386 baseline to SSE2. > 2. Downgrade the Go packages to softfloat. > 3. Build all Go packages with GCCGO on i386. > > As for the option 3, I don't how best is supported by upstream. > But most packages may work, if some specific packages FTBFS after switching > to GCCGO, they need to be removed on i386 unfortunately. > > What people prefer for the 3 options? 1: I'd like to avoid that. package tests, symbols files, anything else is written for x87. It's a change which comes with a lot of extra work from my point of view. 2: No opinion. 3: I didn't check golang vs. gccgo. It seems to work for some packages. Expect some version skew, e.g. bullseye has golang 1.15.x, and gccgo 1.14.x. Extrapolating bookworm that will be golang 1.19.x and gccgo 1.18.x. Matthias
Re: i386 baseline issue for Go packages in Bookworm
On Sun, Apr 18, 2021 at 5:18 AM Tianon Gravi wrote: > > On Sat, 17 Apr 2021 at 10:10, Shengjing Zhu wrote: > > 1. Raise the i386 baseline to SSE2. > > 2. Downgrade the Go packages to softfloat. > > 3. Build all Go packages with GCCGO on i386. > > We've been setting "GO386=387" since src:golang was introduced, so 2. > is already the reality. :D > > What makes Go 1.16 complicated in this regard is that they've renamed > the value to "softfloat" but the bootstrap compiler still needs it set > to "387"... > Hmm, I thought GO386=softfloat is still different to GO386=387. It's still some performance downgrade. I find you have turned all golang docker images to GO386=softfloat, I think we can follow it in Debian. -- Shengjing Zhu
Re: i386 baseline issue for Go packages in Bookworm
On Sat, Apr 17, 2021 at 10:32:26PM +0500, Andrey Rahmatullin wrote: >... > 1) decide "the i386 architecture is for retrocomputing" and disable > building on it for packages that can't run on retro hardware, or > 2) decide "the i386 architecture is for the legacy software" and raise the > baseline to match the amd64 one, >... > Or we could make two architectures, I guess. Two architectures would be a *huge* effort with little benefit. With rare exceptions,[1] doing 1) automatically provides 2) until the year 2038 becomes a real problem for 2) in any case. cu Adrian [1] There are a handful "32bit-only and really needs SSE2" packages.
Re: i386 baseline issue for Go packages in Bookworm
On Sat, 17 Apr 2021 at 10:10, Shengjing Zhu wrote: > 1. Raise the i386 baseline to SSE2. > 2. Downgrade the Go packages to softfloat. > 3. Build all Go packages with GCCGO on i386. We've been setting "GO386=387" since src:golang was introduced, so 2. is already the reality. :D What makes Go 1.16 complicated in this regard is that they've renamed the value to "softfloat" but the bootstrap compiler still needs it set to "387"... See also https://github.com/golang/go/issues/44500 for more details (and/or the failure in https://buildd.debian.org/status/fetch.php?pkg=golang-1.16=i386=1.16.3-1=1618691947=log). I think our "simplest" solution, since we know the buildds don't need softfloat, is what yosifkit suggests in that upstream bug (building the bootstrap compiler explicitly as a separate step, then setting GO386=softfloat for the real build). Maybe also include "sse2-support [i386]" in "Build-Depends" just to be explicit? Another "fun" upstreamism we need to be aware of is https://github.com/golang/go/issues/44505 (upgrading the bootstrap compiler to require 1.16+ for 1.18+). ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Re: i386 baseline issue for Go packages in Bookworm
On Sun, Apr 18, 2021 at 01:42:51AM +0800, Shengjing Zhu wrote: > On Sun, Apr 18, 2021 at 1:32 AM Andrey Rahmatullin wrote: > > 2) decide "the i386 architecture is for the legacy software" and raise the > > baseline to match the amd64 one, > > 2a) also don't build non-library packages there. > > Just FTR, it does't apply to Go packages, as all Go packages are > written after SSE2. > Go was publicly announced in November 2009. Sure, "legacy software" in this context usually means pre-built stuff from outside Debian (including Windows apps via 32-bit Wine). Just bumping the baseline because many packages can't be sanely built with the current one doesn't make much sense to me, because if you can only run this architecture on a CPU that supports SSE2, you most often can just run amd64. -- WBR, wRAR signature.asc Description: PGP signature
Re: i386 baseline issue for Go packages in Bookworm
On Sun, Apr 18, 2021 at 1:32 AM Andrey Rahmatullin wrote: > 2) decide "the i386 architecture is for the legacy software" and raise the > baseline to match the amd64 one, > 2a) also don't build non-library packages there. Just FTR, it does't apply to Go packages, as all Go packages are written after SSE2. Go was publicly announced in November 2009. -- Shengjing Zhu
Re: i386 baseline issue for Go packages in Bookworm
On Sun, Apr 18, 2021 at 01:09:40AM +0800, Shengjing Zhu wrote: > Hi, > > As the release of Go 1.16, upstream no longer supports x87-only > floating-point. > > https://golang.org/doc/go1.16#386 > > > require at least SSE2 support on 386, raising Go's minimum GOARCH=386 > > requirement to the Intel Pentium 4 (released in 2000) or > > AMD Opteron/Athlon 64 (released in 2003). > > So we have 3 options for Go packages on i386 in Bookwarm. > > 1. Raise the i386 baseline to SSE2. > 2. Downgrade the Go packages to softfloat. > 3. Build all Go packages with GCCGO on i386. > > As for the option 3, I don't how best is supported by upstream. > But most packages may work, if some specific packages FTBFS after switching > to GCCGO, they need to be removed on i386 unfortunately. > > What people prefer for the 3 options? Either 1) decide "the i386 architecture is for retrocomputing" and disable building on it for packages that can't run on retro hardware, or 2) decide "the i386 architecture is for the legacy software" and raise the baseline to match the amd64 one, 2a) also don't build non-library packages there. Or we could make two architectures, I guess. -- WBR, wRAR signature.asc Description: PGP signature
i386 baseline issue for Go packages in Bookworm
Hi, As the release of Go 1.16, upstream no longer supports x87-only floating-point. https://golang.org/doc/go1.16#386 > require at least SSE2 support on 386, raising Go's minimum GOARCH=386 > requirement to the Intel Pentium 4 (released in 2000) or > AMD Opteron/Athlon 64 (released in 2003). So we have 3 options for Go packages on i386 in Bookwarm. 1. Raise the i386 baseline to SSE2. 2. Downgrade the Go packages to softfloat. 3. Build all Go packages with GCCGO on i386. As for the option 3, I don't how best is supported by upstream. But most packages may work, if some specific packages FTBFS after switching to GCCGO, they need to be removed on i386 unfortunately. What people prefer for the 3 options?
