-
Notifications
You must be signed in to change notification settings - Fork 95
add workaround for missing TLS certificates when cross compiled without CGO #13
add workaround for missing TLS certificates when cross compiled without CGO #13
Conversation
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? |
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: 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 |
Hmmm, I just tried |
you don't get a msg at compile time - you get this message when you run the compiled binary: |
Yeah, I know. This is what I did:
It doesn't complain. Is this normal? I'm on OS X if that matters. |
I tried it too - it looks like that if you compile for your local platform it ignores to deactivate CGO :-( This is what you get without cgo cross compiled:
Here the link to the OSX binary compiled on linux: you could also use the Dockerfile to create this binary |
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? |
I have done some research too but it looks that OSX toolchain is not availble I would prefer not to use this hacks but there is no official solution for this problem. |
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? |
@SvenDowideit or @steeve can you confirm that there is a problem compiling for OSX with a linux docker container |
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.. |
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 |
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 |
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. |
To summarize, we need For OSX, we can use xchain to build a OSX toolchain for Linux. |
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 |
@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? |
Unfortunately not yet. Everyone, you can grab the Win32 toolchain at http://crossgcc.rts-software.org/doku.php?id=compiling_for_win32 |
You can check these these files if you need further information for cross compilation: |
I will have a look at it |
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. |
Seems we have three options here…
@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 :( |
@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. |
At least until we have proper Docker images for cross compilation. After which we could switch to an automated fashion. |
No problem. |
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) |
Conflicts: boot2docker/util.go
Is there anything new concerning this issue? If this gets resolved we could work on automatic building with Wercker |
@gmlewis and @crosbymichael - do we have any path forward to get linux cross-compiling an OSX binary that can do https? |
@SvenDowideit - I don't know the answer to that question. |
We could use |
For the lazy: The netgo build tagRelevant CLs: CL 7100050 Go binaries, if not using cgo, are usually statically linked. When importing the A new build tag,
You also need to specify |
In other words, compiling with |
ooo, that would be sweet! please - make it so :) |
@steeve I thought it's because the pure Go |
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). |
@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 This would majorly simplify the cli build step - as I could delegate it to hub the same way we do for the iso. |
Confirmed:
|
yay, more Automated builds for 1.2.0 here we come :) |
actually, I'll re-open this - we need to change the build and release docs to only use the Dockerfile builds |
@SvenDowideit I'm wondering why it's working now? I don't recall seeing any changes from Go regarding this problem. Strange. |
My take on it is that they removed the limitation to use CGO on another OS. |
I found it. Go 1.3 supports cross compiling with |
@SvenDowideit you might want to specify the version of Go (1.3+) in the doc about this issue. |
fix fo #11
based on https://groups.google.com/d/msg/golang-nuts/tIK1ON3Pq6s/nDPLWG6XBt0J