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
{{ message }}
Repository navigation
build: remove -Werror from cmd/dist build for Go 1.4 release branch #12345
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.
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.
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.
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.
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.
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.
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.
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.
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.
-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.
Activity
minux commentedon Aug 26, 2015
bradfitz commentedon Aug 26, 2015
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.
[-]Go 1.4 fails to compile with clang 3.7[/-][+]build: Go 1.4 fails to compile with clang 3.7[/+]bradfitz commentedon Aug 26, 2015
@minux, that is a fair point.
jlaffaye commentedon Aug 26, 2015
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 commentedon Aug 26, 2015
minux commentedon Aug 26, 2015
ianlancetaylor commentedon Aug 26, 2015
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 commentedon Aug 26, 2015
rsc commentedon Aug 26, 2015
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 commentedon Aug 26, 2015
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.
5 remaining items
andrewchambers commentedon Aug 27, 2015
-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.
cmd/dist: remove -Werror from CFLAGS
jiri-profile-v23: Use Go 1.4.3 and not 1.4.2 for bootstrapping.
Bump bootstrap to 1.4.3 to fix compiler error (#4)
Bump bootstrap to 1.4.3 to fix compiler error (#4)
Bump bootstrap to 1.4.3 to fix compiler error (#4)
cmd/dist: remove -Werror from CFLAGS
cmd/dist: remove -Werror from CFLAGS
cmd/dist: remove -Werror from CFLAGS
cmd/dist: remove -Werror from CFLAGS
cmd/dist: remove -Werror from CFLAGS
path/filepath: add SplitListSeq and SplitNames