You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #31382, @mikioh asks an interesting questions about the maintenance of golang.org/x packages on gccgo.
How are we sure that the changes made in golang.org/x will work on gccgo ?
For Go toolchain, they are builders on every GOOS/GOARCH which check that it's working but what about the Gccgo toolchain ? Do we assume that if it works on Go, it must work on Gccgo ?
The core code of each package should indeed work, after all that's just Go code. But what about special gccgo files, like in x/sys/unix for syscalls, or all the Go assembly files which cannot be built on gccgo, like in x/crypto ?
At present we have no formal testing that the x/ packages work with gccgo. In general we have no formal testing of gccgo at all. Yes, it would be nice to fix this.
That said, most of the x/ packages do work with gccgo.
In #31382, @mikioh asks an interesting questions about the maintenance of golang.org/x packages on gccgo.
How are we sure that the changes made in golang.org/x will work on gccgo ?
For Go toolchain, they are builders on every GOOS/GOARCH which check that it's working but what about the Gccgo toolchain ? Do we assume that if it works on Go, it must work on Gccgo ?
The core code of each package should indeed work, after all that's just Go code. But what about special gccgo files, like in x/sys/unix for syscalls, or all the Go assembly files which cannot be built on gccgo, like in x/crypto ?
CC @bradfitz @ianlancetaylor
The text was updated successfully, but these errors were encountered: