Skip to content
This repository has been archived by the owner on Feb 27, 2018. It is now read-only.

add workaround for missing TLS certificates when cross compiled without CGO #13

Conversation

aheissenberger
Copy link
Contributor

@riobard
Copy link
Contributor

riobard commented Feb 24, 2014

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
Copy link
Contributor Author

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
Copy link
Contributor

riobard commented Feb 24, 2014

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
Copy link
Contributor Author

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

@riobard
Copy link
Contributor

riobard commented Feb 24, 2014

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
Copy link
Contributor Author

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
Copy link
Contributor

riobard commented Feb 24, 2014

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
Copy link
Contributor Author

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
Copy link
Contributor

riobard commented Feb 24, 2014

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
Copy link
Contributor Author

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

@SvenDowideit
Copy link
Contributor

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
Copy link
Contributor

steeve commented Feb 24, 2014

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
Copy link
Contributor

steeve commented Feb 24, 2014

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
Copy link
Contributor

steeve commented Feb 24, 2014

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
Copy link
Contributor

steeve commented Feb 24, 2014

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
Copy link
Contributor

steeve commented Feb 24, 2014

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
Copy link
Contributor

riobard commented Feb 24, 2014

@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
Copy link
Contributor

steeve commented Feb 24, 2014

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
Copy link
Contributor

steeve commented Feb 24, 2014

@aheissenberger
Copy link
Contributor Author

I will have a look at it

@SvenDowideit
Copy link
Contributor

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
Copy link
Contributor

riobard commented Feb 25, 2014

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
Copy link
Contributor

steeve commented Feb 25, 2014

@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
Copy link
Contributor

steeve commented Feb 25, 2014

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

@riobard
Copy link
Contributor

riobard commented Feb 25, 2014

No problem.

@SvenDowideit
Copy link
Contributor

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)

@riobard riobard mentioned this pull request Feb 26, 2014
@schickling
Copy link

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

@SvenDowideit
Copy link
Contributor

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

@gmlewis
Copy link
Contributor

gmlewis commented May 1, 2014

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

@steeve
Copy link
Contributor

steeve commented May 3, 2014

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

@steeve
Copy link
Contributor

steeve commented May 3, 2014

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
Copy link
Contributor

steeve commented May 3, 2014

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

@SvenDowideit
Copy link
Contributor

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

@riobard
Copy link
Contributor

riobard commented May 5, 2014

@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
Copy link
Contributor

tianon commented May 5, 2014

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
Copy link
Contributor

@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
Copy link
Contributor

steeve commented Jul 10, 2014

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
Copy link
Contributor

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

@SvenDowideit
Copy link
Contributor

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

@riobard
Copy link
Contributor

riobard commented Jul 11, 2014

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

@steeve
Copy link
Contributor

steeve commented Jul 11, 2014

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
Copy link
Contributor

riobard commented Jul 12, 2014

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

@riobard
Copy link
Contributor

riobard commented Jul 12, 2014

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants