FAQ
After just reading the contribution guidelines I thought to first send a small mail before putting in a change to fix a small bug…

While cross compiling some code on my Mac with targeted for Linux/AMD64 I received this error: /usr/bin/ld: unrecognized option '--build-id=none’

Now I know why this is added (see https://codereview.appspot.com/119460043 for more details), but it's buggy as it checks for the buildContext.GOOS instead of the runtime.GOOS. So in the case of cross compiling, it will add ‘—build-id=node` even if the OS your compiling on is not listed in the switch statements' case.

So would it be OK to just go ahead and put in a minor, minor change for this?

Cheers,

Sander



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

Search Discussions

  • Minux at May 14, 2015 at 10:33 pm

    On Thu, May 14, 2015 at 2:47 PM, Sander van Harmelen wrote:

    After just reading the contribution guidelines I thought to first send a
    small mail before putting in a change to fix a small bug…

    While cross compiling some code on my Mac with targeted for Linux/AMD64 I
    received this error: /usr/bin/ld: unrecognized option '--build-id=none’

    Now I know why this is added (see https://codereview.appspot.com/119460043
    for more details), but it's buggy as it checks for the buildContext.GOOS
    instead of the runtime.GOOS. So in the case of cross compiling, it will add
    ‘—build-id=node` even if the OS your compiling on is not listed in the
    switch statements' case.

    So would it be OK to just go ahead and put in a minor, minor change for
    this?
    Are you cross compiling with cgo enabled? In that case, you should provide a
    cross compilation toolchain for linux/amd64, and definitely not using the
    /usr/bin/ld
    to link the cgo intermediate object files.

    I think the go tool is working as intended, it should use buildContext.GOOS
    not
    runtime.GOOS.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Sander van Harmelen at May 15, 2015 at 7:53 am
    Thanks for the pointer and sorry for the noise!

    Works as expected when using CC=/path/to/gcc_cross_compiler

    Sander


    On 15 May 2015, at 00:32:37, minux wrote:


    On Thu, May 14, 2015 at 2:47 PM, Sander van Harmelen wrote:
    After just reading the contribution guidelines I thought to first send a small mail before putting in a change to fix a small bug…

    While cross compiling some code on my Mac with targeted for Linux/AMD64 I received this error: /usr/bin/ld: unrecognized option '--build-id=none’

    Now I know why this is added (see https://codereview.appspot.com/119460043 <https://codereview.appspot.com/119460043> for more details), but it's buggy as it checks for the buildContext.GOOS instead of the runtime.GOOS. So in the case of cross compiling, it will add ‘—build-id=node` even if the OS your compiling on is not listed in the switch statements' case.

    So would it be OK to just go ahead and put in a minor, minor change for this?

    Are you cross compiling with cgo enabled? In that case, you should provide a
    cross compilation toolchain for linux/amd64, and definitely not using the /usr/bin/ld
    to link the cgo intermediate object files.

    I think the go tool is working as intended, it should use buildContext.GOOS not
    runtime.GOOS.

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

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Sander van Harmelen at May 27, 2015 at 9:11 am
    I would like to put in a change that adds a new XML tag to omit empty parents if the `omitempty` tag is set and the value is in fact empty.

    This seems to have been discussed a couple of times before [1][2], but I didn’t see any actual change for it. So if ok with the suggested change, I would like to start implementing it and offering as a change to the language. As in the discussions referenced below, see an example use case:

    http://play.golang.org/p/m2rU4cPOBo <http://play.golang.org/p/m2rU4cPOBo>

    What is the expected output?
    <OmitEmpty></OmitEmpty>

    What do you see instead?
    <OmitEmpty><Vars></Vars></OmitEmpty>

    Initially it was discussed to change the `omitempty` flag, but that would break backwards compatibility. So Russ suggested to add another tag like `omitparents` instead, as a way to “fix" these use cases.

    Please let me know any concerns and/or if I could/should start working on this.

    Thanks,

    Sander


    [1] https://github.com/golang/go/issues/4168
    [2] https://github.com/golang/go/issues/7233

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at May 28, 2015 at 3:24 am

    On Wed, May 27, 2015 at 7:11 PM, Sander van Harmelen wrote:
    This seems to have been discussed a couple of times before [1][2], but I
    didn’t see any actual change for it. So if ok with the suggested change, I
    would like to start implementing it and offering as a change to the
    language.
    I think that https://github.com/golang/go/issues/7233 is the best
    place to discuss this.

    In any case, the standard library is currently in feature freeze up
    until the Go 1.5 release, due August 1, so I'd recommend pinging that
    bug and this thread once the tree is re-opened for new features.

    https://groups.google.com/d/msg/golang-dev/otCULnOjs7I/kmNcWjvcMvYJ

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedMay 14, '15 at 10:27p
activeMay 28, '15 at 3:24a
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase