Skip to content

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

Closed
madisongh/meta-golang
#4

Description

@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

Activity

  1. minux commented on Aug 26, 2015

    @minux
    Member
  2. bradfitz commented on Aug 26, 2015

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

  3. added this to the Unplanned milestone on Aug 26, 2015
  4. changed the title [-]Go 1.4 fails to compile with clang 3.7[/-] [+]build: Go 1.4 fails to compile with clang 3.7[/+] on Aug 26, 2015
  5. bradfitz commented on Aug 26, 2015

    @bradfitz
    Contributor

    @minux, that is a fair point.

  6. jlaffaye commented on Aug 26, 2015

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

  7. minux commented on Aug 26, 2015

    @minux
    Member
  8. minux commented on Aug 26, 2015

    @minux
    Member
  9. ianlancetaylor commented on Aug 26, 2015

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

  10. minux commented on Aug 26, 2015

    @minux
    Member
  11. rsc commented on Aug 26, 2015

    @rsc
    Contributor

    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.

  12. ianlancetaylor commented on Aug 26, 2015

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

  13. 5 remaining items

  14. andrewchambers commented on Aug 27, 2015

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

  15. added a commit that references this issue on Sep 3, 2015
    a527bdb
  16. locked and limited conversation to collaborators on Sep 22, 2016
  17. added 2 commits that reference this issue on Jun 25, 2018
    39f11e1
    1c79389
  18. added a commit that references this issue on Jul 9, 2018
    4c8a683
  19. added a commit that references this issue on Jul 20, 2018
    a36be74
  20. added a commit that references this issue on Jul 30, 2018
    b23b3ea
  21. added a commit that references this issue on Feb 24, 2026
    0dd20a2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions