So you unconditionally build a set of cross-compilers? How does this affect build time?

@7c6f434c Speaking anecdotally, I didn't notice much of a difference in build time - the initial compilation & test pass comprises most of the build time from what I can tell. I can time the two if you'd like real numbers.

@7c6f434c Speaking anecdotally, I didn't notice much of a difference in build time - the initial compilation & test pass comprises most of the build time from what I can tell. I can time the two if you'd like real numbers.

I don't want real numbers, I want @viric to say if always doing this is
a good idea (I am not a Golang user).

I just wanted to make sure it is not a 2× slowdown first (if it were,
it would have to be optional and no second opinions would be needed).

@7c6f434c

I just wanted to make sure it is not a 2× slowdown first (if it were,
it would have to be optional and no second opinions would be needed).

Well, looks like I was wrong:

nix-build ~/src/nixpkgs -A go  440.18s user 135.64s system 168% cpu 5:41.64 total
nix-build ~/src/nixpkgs -A go  981.65s user 280.00s system 189% cpu 11:06.19 total

I'll make it an option.

As for me, the option could be there, but you can enable it by default.

I'd also enjoy this go cross compilation.

On Wed, Sep 03, 2014 at 12:39:50PM -0700, Charles Strahan wrote:

@7c6f434c

I just wanted to make sure it is not a 2× slowdown first (if it were,
it would have to be optional and no second opinions would be needed).

Well, looks like I was wrong:

nix-build ~/src/nixpkgs -A go  440.18s user 135.64s system 168% cpu 5:41.64 total
nix-build ~/src/nixpkgs -A go  981.65s user 280.00s system 189% cpu 11:06.19 total

I'll make it an option.

---

Reply to this email directly or view it on GitHub:
#3603 (comment)

As for me, the option could be there, but you can enable it by default.

I'd also enjoy this go cross compilation.

"default" = Golang used for golang-using packages in NixPkgs. Why should
this have cross compilation (@viric)

Of course, like with pythonFull, many human users will just use
goWithCross in their environment.

On Wed, Sep 03, 2014 at 12:52:28PM -0700, Michael Raskin wrote:

As for me, the option could be there, but you can enable it by default.

I'd also enjoy this go cross compilation.

"default" = Golang used for golang-using packages in NixPkgs. Why should
this have cross compilation (@viric)

Of course, like with pythonFull, many human users will just use
goWithCross in their environment.

I agree with you. Thank you!

I think the go package should just build the cross-compilers by default. Having multiple packages like goWithCross is generally something to avoid. It compiles fast and it's useful.

@cstrahan @viric so, what is the best direction to take here, after all the discussion?

@cstrahan I think you have considered the arguments of all the sides, so feel free to merge yourself whatever version you consider the best.

I'll make cross compilation support optional (but enabled by default). I'll do that tomorrow.

@cstrahan ?

@cstrahan So? Or is there another solution committed by now?

@cstrahan ping?

I tried applying the changes to our Go 1.4, but it fails on the first cross-compiler:

# Building packages and commands for darwin/386.
runtime
errors
sync/atomic
unicode
unicode/utf8
math
sort
encoding
unicode/utf16
container/list
crypto/subtle
runtime/cgo
container/ring
image/color
sync
runtime/race
container/heap
image/color/palette
io
syscall
hash
crypto/cipher
hash/crc32
crypto/hmac
hash/adler32
hash/crc64
hash/fnv
# runtime/cgo
In file included from /nix/store/483br9kb3f5igsgmb6aqsjhl2ipj2bxr-glibc-2.21/include/features.h:389:0,
                 from /nix/store/483br9kb3f5igsgmb6aqsjhl2ipj2bxr-glibc-2.21/include/errno.h:28,
                 from runtime/cgo/cgo.go:46:
/nix/store/483br9kb3f5igsgmb6aqsjhl2ipj2bxr-glibc-2.21/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
 # include <gnu/stubs-32.h>
                           ^
compilation terminated.

I don't know why this stopped working, nor how to pull in a 32-bit glibc. If someone can lend a hand here, I can wrap this up and merge it.

On the other hand, Go 1.5 (supposedly) supports cross compilation by default, and since we have Go 1.5, I don't see how cross-compilation is important for Go 1.4 - unless someone actually has a use case for it. So, I'm of the opinion that we should just close this PR.

Thoughts?

Any further ideas? :(

I think this is resolved, thanks to the latest Go releases; closing.