FAQ
Hello,

As part of https://groups.google.com/d/topic/golang-nuts/VM4wfgo0ues/discussion
I have started to worry that we are not testing tip with cgo disabled
enough. For reasons spanning personal preference to some inexplicable
decisions by the OSX/homebrew folks, disabling cgo is a lot more
common that our selection of dashboard builders gives us visibility.

I think we only need one builder per major GOOS to be running without
cgo, but every permutation would be preferable. The former could be
solved just by picking a sacrificial builder, the latter probably by
extending the build key to include -cgo, eg,
linux-amd64-cgo{,-lastname}.

What is the general feeling about this ? Is CGO_ENABLED=0 under tested
at the moment ?

Cheers

Dave

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • John Asmuth at Feb 11, 2013 at 7:21 pm
    I think that disabling CGO is mostly useful for cross-compilation (where
    CGO_ENABLED=0 is enforced). Rigorous testing for cross-compilation is
    pretty desirable, in my opinion. It's one of those things that Go makes
    really easy, and is often really hard with other languages.


    On Monday, February 11, 2013 5:40:41 AM UTC-5, Dave Cheney wrote:

    Hello,

    As part of
    https://groups.google.com/d/topic/golang-nuts/VM4wfgo0ues/discussion
    I have started to worry that we are not testing tip with cgo disabled
    enough. For reasons spanning personal preference to some inexplicable
    decisions by the OSX/homebrew folks, disabling cgo is a lot more
    common that our selection of dashboard builders gives us visibility.

    I think we only need one builder per major GOOS to be running without
    cgo, but every permutation would be preferable. The former could be
    solved just by picking a sacrificial builder, the latter probably by
    extending the build key to include -cgo, eg,
    linux-amd64-cgo{,-lastname}.

    What is the general feeling about this ? Is CGO_ENABLED=0 under tested
    at the moment ?

    Cheers

    Dave
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Feb 11, 2013 at 9:32 pm
    Yup, that is (yet) another aspect I overlooked. I think I can solve
    that by setting up a jenkins job to cross compile to all arches.
    On Tue, Feb 12, 2013 at 6:21 AM, John Asmuth wrote:
    I think that disabling CGO is mostly useful for cross-compilation (where
    CGO_ENABLED=0 is enforced). Rigorous testing for cross-compilation is pretty
    desirable, in my opinion. It's one of those things that Go makes really
    easy, and is often really hard with other languages.


    On Monday, February 11, 2013 5:40:41 AM UTC-5, Dave Cheney wrote:

    Hello,

    As part of
    https://groups.google.com/d/topic/golang-nuts/VM4wfgo0ues/discussion
    I have started to worry that we are not testing tip with cgo disabled
    enough. For reasons spanning personal preference to some inexplicable
    decisions by the OSX/homebrew folks, disabling cgo is a lot more
    common that our selection of dashboard builders gives us visibility.

    I think we only need one builder per major GOOS to be running without
    cgo, but every permutation would be preferable. The former could be
    solved just by picking a sacrificial builder, the latter probably by
    extending the build key to include -cgo, eg,
    linux-amd64-cgo{,-lastname}.

    What is the general feeling about this ? Is CGO_ENABLED=0 under tested
    at the moment ?

    Cheers

    Dave
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrew Gerrand at Feb 12, 2013 at 4:32 am

    On 11 February 2013 21:40, Dave Cheney wrote:

    some inexplicable
    decisions by the OSX/homebrew folks
    What's this? Mac homebrew builds Go without cgo?

    Andrew

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Feb 12, 2013 at 4:37 am
    Not all the time, but problems reported on IRC point to a higher than
    expected number of Homebrew Go installs having cgo disabled by
    accident, or on purpose.
    On Tue, Feb 12, 2013 at 3:25 PM, Andrew Gerrand wrote:
    On 11 February 2013 21:40, Dave Cheney wrote:

    some inexplicable
    decisions by the OSX/homebrew folks

    What's this? Mac homebrew builds Go without cgo?

    Andrew
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrew Gerrand at Feb 12, 2013 at 5:09 am

    On 11 February 2013 21:40, Dave Cheney wrote:

    What is the general feeling about this ? Is CGO_ENABLED=0 under tested
    at the moment ?
    I generally agree that we should test CGO_ENABLED=0. It would be easier if
    we could make the builders aware of the flag, so that existing builders
    could run both cgo and non-cgo builds in parallel (or concurrently, rather).

    Andrew

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Feb 12, 2013 at 5:15 am
    That would be the gold plated solution. I have raised
    https://code.google.com/p/go/issues/detail?id=4795 and assigned it to
    myself to work on sometime.
    On Tue, Feb 12, 2013 at 4:08 PM, Andrew Gerrand wrote:
    On 11 February 2013 21:40, Dave Cheney wrote:

    What is the general feeling about this ? Is CGO_ENABLED=0 under tested
    at the moment ?

    I generally agree that we should test CGO_ENABLED=0. It would be easier if
    we could make the builders aware of the flag, so that existing builders
    could run both cgo and non-cgo builds in parallel (or concurrently, rather).

    Andrew
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 11, '13 at 10:40a
activeFeb 12, '13 at 5:15a
posts7
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase