Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jlaffaye opened this issue Aug 26, 2015 · 15 comments · Fixed by madisongh/meta-golang#4
Closed

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

jlaffaye opened this issue Aug 26, 2015 · 15 comments · Fixed by madisongh/meta-golang#4

Comments

@jlaffaye
Copy link

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
Copy link
Member

minux commented Aug 26, 2015 via email

@bradfitz
Copy link
Contributor

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 bradfitz added this to the Unplanned milestone Aug 26, 2015
@bradfitz bradfitz changed the title Go 1.4 fails to compile with clang 3.7 build: Go 1.4 fails to compile with clang 3.7 Aug 26, 2015
@bradfitz
Copy link
Contributor

@minux, that is a fair point.

@jlaffaye
Copy link
Author

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
Copy link
Member

minux commented Aug 26, 2015 via email

@minux
Copy link
Member

minux commented Aug 26, 2015 via email

@ianlancetaylor
Copy link
Contributor

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.

@ianlancetaylor ianlancetaylor modified the milestones: Go1.4.3, Unplanned Aug 26, 2015
@minux
Copy link
Member

minux commented Aug 26, 2015 via email

@rsc
Copy link
Contributor

rsc commented 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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

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 rsc changed the title build: Go 1.4 fails to compile with clang 3.7 build: remove -Werror from cmd/dist build for Go 1.4 release branch Aug 27, 2015
@rsc
Copy link
Contributor

rsc commented Aug 27, 2015

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
Copy link

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

@andrewchambers
Copy link

-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.

minux added a commit that referenced this issue Sep 3, 2015
Fixes #12345.

Change-Id: I43d91e3f33171c333803036b29c3238c6aff3c60
Reviewed-on: https://go-review.googlesource.com/13962
Reviewed-by: Andrew Gerrand <adg@golang.org>
@minux minux closed this as completed Sep 12, 2015
vanadium-bot pushed a commit to vanadium-archive/go.devtools that referenced this issue Mar 23, 2016
For targets where the release version of Go 1.6 is not currently
supported (specifically --target=amd64-ios and other *-ios ones),
the Go profile builds go1.4.2 from sources and then builds the
later version of Go from that. This breaks with XCode 7.3 on
OS X because it runs into golang/go#12345

As a quick fix, use 1.4.3 for bootstrapping.
A more appropriate but involved fix might be to just use the release
Go 1.6 as the bootstrapping compiler for the patched Go 1.6.

Change-Id: Iefac907c0fc33a2505ded7e2f8ed18e6d54df4b3
madisongh pushed a commit to madisongh/meta-golang that referenced this issue Sep 8, 2016
This fixes golang/go#12345 which
you can encounter with newer gcc.
madisongh pushed a commit to madisongh/meta-golang that referenced this issue Sep 8, 2016
This fixes golang/go#12345 which
you can encounter with newer gcc.
madisongh pushed a commit to madisongh/meta-golang that referenced this issue Sep 8, 2016
This fixes golang/go#12345 which
you can encounter with newer gcc.
@golang golang locked and limited conversation to collaborators Sep 22, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
Fixes golang#12345.

Change-Id: I43d91e3f33171c333803036b29c3238c6aff3c60
Reviewed-on: https://go-review.googlesource.com/13962
Reviewed-by: Andrew Gerrand <adg@golang.org>
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 26, 2018
Fixes golang#12345.

Change-Id: I43d91e3f33171c333803036b29c3238c6aff3c60
Reviewed-on: https://go-review.googlesource.com/13962
Reviewed-by: Andrew Gerrand <adg@golang.org>
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
Fixes golang#12345.

Change-Id: I43d91e3f33171c333803036b29c3238c6aff3c60
Reviewed-on: https://go-review.googlesource.com/13962
Reviewed-by: Andrew Gerrand <adg@golang.org>
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 20, 2018
Fixes golang#12345.

Change-Id: I43d91e3f33171c333803036b29c3238c6aff3c60
Reviewed-on: https://go-review.googlesource.com/13962
Reviewed-by: Andrew Gerrand <adg@golang.org>
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018
Fixes golang#12345.

Change-Id: I43d91e3f33171c333803036b29c3238c6aff3c60
Reviewed-on: https://go-review.googlesource.com/13962
Reviewed-by: Andrew Gerrand <adg@golang.org>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants