build: remove -Werror from cmd/dist build for Go 1.4 release branch

[jlaffaye]

This is a serious issue as clang is the default compiler of FreeBSD, and go 1.4 is needed to bootstrap Go 1.5+

The bug on FreeBSD bugtracker (include error logs and proposed patchs): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202662

[minux]

This brought up the issue of whether we should continue maintaining Go 1.4 given that it's the last version without circular dependency on another Go compiler. Normally, once a new stable release is released, we will stop maintaining the older ones, but I can see why this might not be desirable for 1.4.

[bradfitz]

FreeBSD should feel free to silence any clang undefined behavior warnings from versions of clang that are newer than we ever built Go 1.4 with.

Because Go 1.5 is now out, and because Go 1.5 no longer contains any C code, we probably won't be making such changes upstream, nor in the Go 1.4 release branch (which we only use for critical problems).

If you'd like us to review any patches, please email golang-dev@ or ping this bug and somebody can take a look.

/cc @ianlancetaylor for the linker parts.

[bradfitz]

@minux, that is a fair point.

[jlaffaye]

I could apply patches to Go source files in the FreeBSD port, but having fixes in upstream would avoid every package maintainer to maintain their own set of patches.

[minux]

I think we can slightly soften the rules regarding 1.4 point releases. We can definitely import the 2nd patch (uvlong) as it's obviously safe and fix a compilation problem. (On the other hand, disable the warning is also a valid workaround, but it's slightly harder as the code is being compiled by cmd/dist.) The 1st problem is slightly different. I think a valid workaround is to disable cgo when building Go 1.4 (export CGO_ENABLED=0 before running make.bash), because bootstrapping Go 1.5 doesn't require cgo.

[minux]

My proposal is we continue to maintain Go 1.4 for already supported platform for the sole purpose of bootstrapping Go 1.5+ for as long as it's reasonable, but we don't issue new point releases. Interested parties can always get from git. For example, future OS releases might complete break Go 1.4's net package, but as it's not required for bootstrapping Go 1.5+, we won't fix those problems. The exception is that if the required change is too big, we can stop supporting that platform in Go 1.4, but I think it's a fairly unlikely event, at least for the near future.

[ianlancetaylor]

In general I agree with minux that we need to ensure that Go 1.4 builds at least well enough to build Go 1.5. I actually think that we might need to make new point release in some cases.

In this case, I think we should consider a patch for 1.4 that drops -Werror from the list of command line options. And I think that the FreeBSD build process should set CGO_ENABLED=0 when building Go 1.4. I think those two steps should fix the FreeBSD build.

[minux]

Yeah, dropping -Werror is much better and more future-proof. My reason for not making new point releases is because I think making the binary distributions is too time consuming. For those build issues, we just need to do a new source code release.

[rsc]

I don't believe that Go 1.4 needs to build anywhere except linux/amd64 and darwin/amd64 (just to take an extreme position). We did not backport linux/ppc64 to Go 1.4 just to make Go 1.5 build there. The requirement is "Go 1.4 or later". The or later is implemented nearly trivially by bootstrap.bash.

[ianlancetaylor]

Building only on GNU/Linux and Darwin works for us but seems a little unfair to FreeBSD. In any case these particular issues are presumably going to arise on other platforms too as they move to newer versions of clang.

I'm only proposing one patch to 1.4 at this time: drop -Werror from cmd/dist/build.c.

@minux I agree that only a new source release is needed, if anything is needed.

[bradfitz]

I agree that it's unfair to make other operating systems require binary blobs to bootstrap.

Instead of making this conversation about operating systems, though, what if the question is: should we maintain Go 1.4 enough such that it can always build with the latest versions of {gcc, clang}? Presumably other Linux distros will also only contain clang 3.7+?

[jaguilar]

What does Clang do for this problem? Does the last non-bootstrapping version still build on the system C++ compiler for all arches? If not, how long did they maintain that version before they switched over to requiring Clang to build Clang?

[rsc]

OK, let's remove -Werror. But I do not want this to lead to a cascade of additional point releases. I don't have any problem with maintainers maintaining their own patches to make Go 1.4 compile with ever-whinier compilers.

[gopherbot]

CL https://golang.org/cl/13962 mentions this issue.

[andrewchambers]

-Werror is great for programmers, but horrible for distributors/end users. The number of compiler diagnostics will only increase as the years pass. This highlights why go vet is a better design than compiler warnings.