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 my understanding, for most of the OSes, a package implementation doesn't need to be changed according to which compiler is being used.
The only case, I'm thinking of, where a special file is needed is for Oses (like AIX, Solaris and maybe 1.12 Darwin) which haven't the same syscall backend. On Linux or BSDs, syscall.Syscall can be called from both Gc and Gccgo. Correct me if I'm wrong.
But on AIX, Gc syscalls needed //go:linkname and Gccgo ones needed //extern. Therefore a different syscall file is needed. However, the rest of the package should remain unchanged right ?
Note I've checked with gccgo-8 (go1.10) on Linux/amd64 and x/net package tests seems to pass as is.
@ianlancetaylor could you please confirm than these are the only different between Gccgo and Gc compiler on a package implementation ?
I think there are two issues: one is a technical thing and another is an operation thing. Perhaps the latter might be a bit heavy for people who need to work on release engineering, for example, spinning up a new gccgo builder fleet, making sure the maintenance window for both go and gccgo released versions, blah blah. Looks like this issue focuses on the former, so please open a new issue for the latter, as a proposal, like "proposal: x/net or all?: add support for gccgo".
And this issue also must be a proposal?
PS: What happens when we use a pair of x/net-gccgo and stdlib-go or vice versa? Does a single executable file containing two different runtimes, go and gccgo, just work fine?
Ok I now understand the underlying problem. As far as I know, there is no builder for gccgo, and the core team assume that if it works on Gc and it should work on Gccgo too. Because as I say, every x packages (expect x/sys/unix) will work as is on both Gc and Gccgo. I'll open an issue to know how checks are made on gccgo for these x packages.
As far as I know, it's not possible to build an executable with x/net-gccgo and a stdlib-go. Both built packages aren't stored at the same place and are completely independent. If you build an executable with x/net and gccgo, I'll have the gccgo runtime/packages.