FAQ
I'm wondering if there's any plan for adding netgo support to the
distribution build in the same way that CGO_ENABLED has been supported,
such that net apps built with that configuration of the toolchain would, by
default, not require -tags netgo (which is easy to forget, though
admittedly easy to shell alias). The most general mechanism I can think of
for this is the toolchain, perhaps statically, supporting an arbitrary list
of build tags to consider distribution-wide defaults (even more preferable
if supported on a GOPATH basis, e.g. an appengine enabled GOPATH vs one
that is not appengine enabled).

I suspect that this would require a minor extension to the compiled archive
format to distinguish between a static net library caused by CGO_ENABLED=0,
and one caused by the netgo tag. Alternatively, this could involve
introduction of a NETGO environment variable, though that's clearly not the
direction we were headed. In a more general sense, if compiled archives
contained metadata indicating the build tags used, that alleviate much of
the need for the -a build flag, in addition to avoiding subtle bugs caused
by "false positive builds", which when -a is not used, may link against
package archives that don't correspond to supplied build tags.

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

  • Kevin Gillette at Sep 27, 2013 at 6:40 pm
    Rephrased: is there any plan or discussion about allowing the netgo tag to
    be the default on a per GOROOT basis?
    On Monday, September 23, 2013 2:31:09 AM UTC-6, Kevin Gillette wrote:

    I'm wondering if there's any plan for adding netgo support to the
    distribution build in the same way that CGO_ENABLED has been supported,
    such that net apps built with that configuration of the toolchain would, by
    default, not require -tags netgo (which is easy to forget, though
    admittedly easy to shell alias). The most general mechanism I can think of
    for this is the toolchain, perhaps statically, supporting an arbitrary list
    of build tags to consider distribution-wide defaults (even more preferable
    if supported on a GOPATH basis, e.g. an appengine enabled GOPATH vs one
    that is not appengine enabled).

    I suspect that this would require a minor extension to the compiled
    archive format to distinguish between a static net library caused by
    CGO_ENABLED=0, and one caused by the netgo tag. Alternatively, this could
    involve introduction of a NETGO environment variable, though that's clearly
    not the direction we were headed. In a more general sense, if compiled
    archives contained metadata indicating the build tags used, that alleviate
    much of the need for the -a build flag, in addition to avoiding subtle bugs
    caused by "false positive builds", which when -a is not used, may link
    against package archives that don't correspond to supplied build tags.
    --
    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.
  • Ian Lance Taylor at Sep 27, 2013 at 7:54 pm

    On Fri, Sep 27, 2013 at 11:40 AM, Kevin Gillette wrote:
    Rephrased: is there any plan or discussion about allowing the netgo tag to
    be the default on a per GOROOT basis?
    I'm not aware of any such plan or discussion.

    I'm not sure such a facility would be widely used. What is the
    compelling use case?

    Ian
    On Monday, September 23, 2013 2:31:09 AM UTC-6, Kevin Gillette wrote:

    I'm wondering if there's any plan for adding netgo support to the
    distribution build in the same way that CGO_ENABLED has been supported, such
    that net apps built with that configuration of the toolchain would, by
    default, not require -tags netgo (which is easy to forget, though admittedly
    easy to shell alias). The most general mechanism I can think of for this is
    the toolchain, perhaps statically, supporting an arbitrary list of build
    tags to consider distribution-wide defaults (even more preferable if
    supported on a GOPATH basis, e.g. an appengine enabled GOPATH vs one that is
    not appengine enabled).

    I suspect that this would require a minor extension to the compiled
    archive format to distinguish between a static net library caused by
    CGO_ENABLED=0, and one caused by the netgo tag. Alternatively, this could
    involve introduction of a NETGO environment variable, though that's clearly
    not the direction we were headed. In a more general sense, if compiled
    archives contained metadata indicating the build tags used, that alleviate
    much of the need for the -a build flag, in addition to avoiding subtle bugs
    caused by "false positive builds", which when -a is not used, may link
    against package archives that don't correspond to supplied build tags.
    --
    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.
  • Kevin Gillette at Sep 27, 2013 at 8:17 pm
    The use case (whether or not it's sufficiently compelling) is to provide an
    analogue to the often used `CGO_ENABLED=0 ./all.bash` build, but for those
    who want to use cgo for some things while still statically linking net
    apps. It'd also provide an excuse to look at solving making the -a build
    flag less important, by recording build flags in compiled .a archives.
    On Friday, September 27, 2013 1:54:09 PM UTC-6, Ian Lance Taylor wrote:

    On Fri, Sep 27, 2013 at 11:40 AM, Kevin Gillette
    <extempor...@gmail.com <javascript:>> wrote:
    Rephrased: is there any plan or discussion about allowing the netgo tag to
    be the default on a per GOROOT basis?
    I'm not aware of any such plan or discussion.

    I'm not sure such a facility would be widely used. What is the
    compelling use case?

    Ian
    On Monday, September 23, 2013 2:31:09 AM UTC-6, Kevin Gillette wrote:

    I'm wondering if there's any plan for adding netgo support to the
    distribution build in the same way that CGO_ENABLED has been supported,
    such
    that net apps built with that configuration of the toolchain would, by
    default, not require -tags netgo (which is easy to forget, though
    admittedly
    easy to shell alias). The most general mechanism I can think of for
    this is
    the toolchain, perhaps statically, supporting an arbitrary list of
    build
    tags to consider distribution-wide defaults (even more preferable if
    supported on a GOPATH basis, e.g. an appengine enabled GOPATH vs one
    that is
    not appengine enabled).

    I suspect that this would require a minor extension to the compiled
    archive format to distinguish between a static net library caused by
    CGO_ENABLED=0, and one caused by the netgo tag. Alternatively, this
    could
    involve introduction of a NETGO environment variable, though that's
    clearly
    not the direction we were headed. In a more general sense, if compiled
    archives contained metadata indicating the build tags used, that
    alleviate
    much of the need for the -a build flag, in addition to avoiding subtle
    bugs
    caused by "false positive builds", which when -a is not used, may link
    against package archives that don't correspond to supplied build tags.
    --
    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...@googlegroups.com <javascript:>.
    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.
  • Kevin Gillette at Oct 14, 2013 at 8:34 pm
    I've just run into another use-case: building applications with -race,
    particularly when cgo is involved (in my case, use of sqlite), can take a
    considerable amount of time (~90s on my netbook) to rebuild all necessary
    sources. If support arbitrary for build attributes existed and separately
    compiled archives per combination of attributes could coexist, then the
    cost of changing tags would be minimal. For the purposes of discussion,
    it'd also be ideal to consider the values of GO386 and GOARM variables to
    be such attributes on equal terms, so that an application could be
    optimally built for multiple arm flavors without needing to rebuild all
    dependencies each time, or without needing to manually maintain separate
    GOPATHs.
    On Friday, September 27, 2013 2:17:14 PM UTC-6, Kevin Gillette wrote:

    The use case (whether or not it's sufficiently compelling) is to provide
    an analogue to the often used `CGO_ENABLED=0 ./all.bash` build, but for
    those who want to use cgo for some things while still statically linking
    net apps. It'd also provide an excuse to look at solving making the -a
    build flag less important, by recording build flags in compiled .a archives.
    On Friday, September 27, 2013 1:54:09 PM UTC-6, Ian Lance Taylor wrote:

    On Fri, Sep 27, 2013 at 11:40 AM, Kevin Gillette
    wrote:
    Rephrased: is there any plan or discussion about allowing the netgo tag to
    be the default on a per GOROOT basis?
    I'm not aware of any such plan or discussion.

    I'm not sure such a facility would be widely used. What is the
    compelling use case?

    Ian
    On Monday, September 23, 2013 2:31:09 AM UTC-6, Kevin Gillette wrote:

    I'm wondering if there's any plan for adding netgo support to the
    distribution build in the same way that CGO_ENABLED has been
    supported, such
    that net apps built with that configuration of the toolchain would, by
    default, not require -tags netgo (which is easy to forget, though
    admittedly
    easy to shell alias). The most general mechanism I can think of for
    this is
    the toolchain, perhaps statically, supporting an arbitrary list of
    build
    tags to consider distribution-wide defaults (even more preferable if
    supported on a GOPATH basis, e.g. an appengine enabled GOPATH vs one
    that is
    not appengine enabled).

    I suspect that this would require a minor extension to the compiled
    archive format to distinguish between a static net library caused by
    CGO_ENABLED=0, and one caused by the netgo tag. Alternatively, this
    could
    involve introduction of a NETGO environment variable, though that's
    clearly
    not the direction we were headed. In a more general sense, if
    compiled
    archives contained metadata indicating the build tags used, that
    alleviate
    much of the need for the -a build flag, in addition to avoiding subtle
    bugs
    caused by "false positive builds", which when -a is not used, may link
    against package archives that don't correspond to supplied build tags.
    --
    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...@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.
    To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f27c6fac-4ef8-4a06-a3be-8a03b3934617%40googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 23, '13 at 8:31a
activeOct 14, '13 at 8:34p
posts5
users2
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase