add workaround for missing TLS certificates when cross compiled without CGO

[aheissenberger]

fix fo #11
based on https://groups.google.com/d/msg/golang-nuts/tIK1ON3Pq6s/nDPLWG6XBt0J

[riobard]

Holy cow! This is amazing!! 👍

Just wondering, does this happen on when cross compiling from Linux to OS X, or does it also happen when cross compiling from OS X to Linux?

[aheissenberger]

There is no way at the moment to compile native platform code on linux for OSX or Windows - this is also true if you would try to compile on OSX for Windows. Thats why for cross compiling CGO is not enabled by default. This has effects on all function relying on the native bindings (CGO) for some features.

You can simulate the cross compile on your System by using this to compile the binary:
CGO_ENABLED=0 go build -o boot2docker

can you have a look at the code as it would be good to be merged :-) parts of the code will only be included if compiled with CGO_ENABLED=0

[riobard]

Hmmm, I just tried CGO_ENABLED=0 go build -o boot2docker to build on OS X. It doesn't complain about TLS issues at all… Did I do anything wrong?

[aheissenberger]

you don't get a msg at compile time - you get this message when you run the compiled binary:
boot2docker download

[riobard]

Yeah, I know. This is what I did:

$ CGO_ENABLED=0 go build -o b2d && ./b2d download
2014/02/24 12:47:03 Downloading boot2docker ISO image...
2014/02/24 12:47:04 Latest release is v0.6.0

It doesn't complain. Is this normal? I'm on OS X if that matters.

[aheissenberger]

I tried it too - it looks like that if you compile for your local platform it ignores to deactivate CGO :-(
I was able to simulate your results on linux compiling for linux.

This is what you get without cgo cross compiled:

boot2docker download
2014/02/24 17:35:11 Downloading boot2docker ISO image...
2014/02/24 17:35:12 Failed to get latest release: Get https://api.github.com/repos/boot2docker/boot2docker/releases: x509: failed to load system roots and no roots provided

Here the link to the OSX binary compiled on linux:
https://dl.dropboxusercontent.com/u/3752017/boot2docker

you could also use the Dockerfile to create this binary

[riobard]

Thanks for pointing this out! I've been doing some research regarding cross compiling Go with CGO enabled and found @steeve wrote this a white ago https://gist.github.com/steeve/6905542 and there is a discussion about this here https://code.google.com/p/go/issues/detail?id=4714. Looks to me there is a way to cross compiling with CGO, but I don't know how to make it work.

@steeve could you please comment if it is possible to cross compile from Linux to OS X/Windows with CGO so we don't have to do the hack?

[aheissenberger]

I have done some research too but it looks that OSX toolchain is not availble
http://wiki.lazarus.freepascal.org/Cross_compiling_OSX_on_Linux

I would prefer not to use this hacks but there is no official solution for this problem.

[riobard]

I just tried cross-compiling from a Docker container. So right now cross-compiling from OS X to Linux/Windows works fine. Cross-compiling from Linux to Windows also works. The only problem is cross-compiling from Linux to OS X which triggers the TLS error. Is that correct?

[aheissenberger]

@SvenDowideit or @steeve can you confirm that there is a problem compiling for OSX with a linux docker container

[SvenDowideit]

I'm using the container to build a windows binary, and building works :) doing an init however fails, so I'm trying to figure out why (it works if i call the makeDisk commandline by hand..

[steeve]

Actually, there is a way to cross compile with CGO for other platforms. This is what I use for https://github.com/steeve/libtorrent-go

If you need OSX toolchains, you can find them here: http://crossgcc.rts-software.org/doku.php

[steeve]

The issue is though, we can't cross-compile to OS X with CGO.

Apparently there is a toolchain available at: https://github.com/tatsh/xchain

Then, you'll need to patch Go to handle cross compilation with CGO of other systems. See this: https://gist.github.com/steeve/6905542

[steeve]

So I think the way to go is for us to make images with the proper toolchains (1 image/toolchain or 1 image with everything) and use it to build.

[steeve]

To summarize, we need mingw32 to cross compile for Windows. We can either install it from packages (I'd go that way) or build it via crosstools-ng

For OSX, we can use xchain to build a OSX toolchain for Linux.
Instructions are also available at: http://devs.openttd.org/~truebrain/compile-farm/apple-darwin9.txt

[steeve]

I think in the mean time, we'll build OSX binaries on OSX, but if someone feels like building a toolchain for OSX, that'd be AWE-SOME. Because having an OSX toolchain just a docker pull away is pure win.

[riobard]

@steeve My testing so far shows that everything works fine if we cross-compile from OS X. The only thing that breaks is cross-compiling from Linux to OS X. Would you have time to prepare the image with all the necessary toolchains?

[steeve]

Unfortunately not yet.
I think for now the way to go is to cross compile everything from OSX. It's a pain (since only a few of us can actually build it), but it's a necessary evil for now.

Everyone, you can grab the Win32 toolchain at http://crossgcc.rts-software.org/doku.php?id=compiling_for_win32

[steeve]

You can check these these files if you need further information for cross compilation:
https://github.com/steeve/torrent2http/blob/master/Makefile
https://github.com/steeve/torrent2http/blob/master/Makefile.cross
https://github.com/steeve/libtorrent-go/blob/master/Makefile

[aheissenberger]

I will have a look at it

[SvenDowideit]

All I can say, is that the Dockerfile produces a functional windows exe - all i needed to do was remember to rename it.

frustratingly, I havn't come up with a way to test it all, as the windows vbox running on my linux notebook here results in the boot2docker vbox running in it crashing - telling me that amd64 (and only an i686 was detected ). I don't have spare HW here, so I might need to wait til I do, or until i get back to Australia next week.

[riobard]

Seems we have three options here…

1. Get the right toolchain so cross-compiling works.
2. Cross-compile from OS X for now (since it produces binaries that work on OS X/Linux/Windows)
3. Use the hack by @aheissenberger if cross-compiling from Linux to OS X.

@SvenDowideit I don't think you can run another VirtualBox VM inside a VirtualBox VM. I don't have a dedicated Windows machine to test either. Windows compatibility is our weakest spot :(

[steeve]

@riobard, since you are on OS X and you can cross compile to all platforms, I vote that, for now, you handle the release cycle.

[steeve]

At least until we have proper Docker images for cross compilation. After which we could switch to an automated fashion.

[riobard]

No problem.

[SvenDowideit]

I am walking out to buy a new notebook tonite, so will be working on windows testing and updating the documentation for Wed-> (assuming that all works out)

[schickling]

Is there anything new concerning this issue? If this gets resolved we could work on automatic building with Wercker

[SvenDowideit]

@gmlewis and @crosbymichael - do we have any path forward to get linux cross-compiling an OSX binary that can do https?

[gmlewis]

@SvenDowideit - I don't know the answer to that question.

[steeve]

We could use netgo to get around this: http://dominik.honnef.co/go-tip/2013-09-07/#netgo

[steeve]

For the lazy:

The netgo build tag

Relevant CLs: CL 7100050

Go binaries, if not using cgo, are usually statically linked. When importing the net package (directly or indirectly), however, one ends up with a dynamically linked binary, linking against libc. That’s because the net package, by default, uses cgo to use the system’s resolver, to support for example LDAP. The net package does come with a pure-Go resolver. Until now, it was only used when cgo wasn’t enabled, which means compiling the standard library (or at least net) as well as your own package with CGO_ENABLED=0. But that has the downside of disabling cgo for your entire project, which might not be desirable.

A new build tag, netgo, alleviates this problem by providing a way to build the standard library and your project with a pure-Go net package while still enabling cgo for other uses. In order to reinstall the standard library with netgo, you run

go install -a -tags netgo std

You also need to specify -tags netgo when building your own package, otherwise cgo will overrule and rebuild net every time you build your package. This does allow installing a netgo standard library as the default with cgo as a working alternative, but it also has the added cost of recompiling the net package every time you do not use the netgo tag.

[steeve]

In other words, compiling with CGO_ENABLED=0 should be fine.

[SvenDowideit]

ooo, that would be sweet! please - make it so :)

[riobard]

@steeve I thought it's because the pure Go net package does not have the necessary root certificates? Cross-compiling disables CGO by default since Go 1.1 already (?).

[tianon]

Yes, @riobard is right. "netgo" by itself doesn't fix this problem, it actually causes it (as a side effect). What @aheissenberger has proposed in this PR is the cleanest fix to the issue. See also moby/moby#3683. Docker definitely uses "netgo", and the "solution" for Docker was to stop the client from using SSL (ie, they moved the check into the daemon; a luxury workaround that's not really possible for us).

[SvenDowideit]

@tianon @aheissenberger @riobard @steeve

It seems to me that when I cross compile the mac binary using the Dockerfile now, that it can successfully download the ISO. - can someone please confirm?

This would majorly simplify the cli build step - as I could delegate it to hub the same way we do for the iso.

[steeve]

Confirmed:

~/p/b/boot2docker-cli git:master ❯❯❯ ./boot2docker-v1.1.1-darwin-amd64 download
2014/07/10 18:18:24 Downloading boot2docker ISO image...
2014/07/10 18:18:25 Latest release is v1.1.1
2014/07/10 18:18:34 Success: downloaded https://github.com/boot2docker/boot2docker/releases/download/v1.1.1/boot2docker.iso
    to /Users/steeve/.boot2docker/boot2docker.iso

[SvenDowideit]

yay, more Automated builds for 1.2.0 here we come :)

[SvenDowideit]

actually, I'll re-open this - we need to change the build and release docs to only use the Dockerfile builds

[riobard]

@SvenDowideit I'm wondering why it's working now? I don't recall seeing any changes from Go regarding this problem. Strange.

[steeve]

My take on it is that they removed the limitation to use CGO on another OS.
See https://gist.github.com/steeve/6905542
And now: http://golang.org/src/cmd/go/build.go (line 2093)

[riobard]

I found it. Go 1.3 supports cross compiling with cgo now http://golang.org/doc/go1.3#gocmd.

[riobard]

@SvenDowideit you might want to specify the version of Go (1.3+) in the doc about this issue.