[Docker-maint] Bug#780355: Bug#779503: support gccgo, at least on architectures where golang is not available

[Tianon Gravi]

On 31 March 2015 at 14:36, Matthias Klose <doko at debian.org> wrote:
> Does your testing goes beyond docker.io?  If no, I would claim your testing is
> dubious at best ;)  There are certainly still issues, but to me it starts to
> look usable.  There are other dubious things like how golang-gotools is built in
> Debian ...

I apologise for how harsh my tone here was -- re-reading, it was way
more coarse than it should've been; I was frustrated at the time of
writing and too much of that came out in my response.

I did test beyond Docker (several other Go projects, and all directly
via the Go toolchain "go get", "go build", etc); I don't have lots of
extra time especially since gccgo isn't involved in my day-to-day
work.

Generally, I'm concerned that gccgo claims to be language-compatible
but not necessarily toolchain-compatible (compiler flags come to mind,
since that's what the Docker build system ended up needing changes to
build under gccgo).

Separate from that, it concerns me a great deal that Docker's
integration tests fail (and the daemon itself segfaults) when I
compile it via gccgo.  I'm not saying this is necessarily
representative, but it's an important point to consider IMO, since I
don't think it's going to be the only package that has runtime issues
when compiled with a completely different buildchain.

> I appreciate the testing you do, and I'm interested to see gccgo specific bug
> reports, if these are reproducible with Go 1.4.2. And yes, I would appreciate a
> golang-gotools built from the 1.4 branch in experimental too (golang is outdated
> in experimental, so I updated myself to 1.4.2 and uploaded a package to the
> Launchpad PPA ~doko/toolchain).

We did push Go 1.4.1 to experimental in Jan, but I'll try to find some
cycles to get 1.4.2 up there too; thanks for the prod.

I'll see if I can get the IBM Docker folks to do some testing on their
side, too.  Last I asked, they couldn't reproduce failures with a
gccgo-built daemon, but I'll see if they've specifically run
upstream's test-integration-cli suite against it (since that's the
workload that gets me a segfaulting daemon within just a few tests).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4