karalabe / xgo Goto Github PK

Go CGO cross compiler

License: MIT License

Go 15.65% Shell 44.11% C++ 0.27% C 0.24% Dockerfile 39.74%

xgo's Introduction

xgo - Go CGO cross compiler

Although Go strives to be a cross platform language, cross compilation from one platform to another is not as simple as it could be, as you need the Go sources bootstrapped to each platform and architecture.

The first step towards cross compiling was Dave Cheney's golang-crosscompile package, which automatically bootstrapped the necessary sources based on your existing Go installation. Although this was enough for a lot of cases, certain drawbacks became apparent where the official libraries used CGO internally: any dependency to third party platform code is unavailable, hence those parts don't cross compile nicely (native DNS resolution, system certificate access, etc).

A step forward in enabling cross compilation was Alan Shreve's gonative package, which instead of bootstrapping the different platforms based on the existing Go installation, downloaded the official pre-compiled binaries from the golang website and injected those into the local toolchain. Since the pre-built binaries already contained the necessary platform specific code, the few missing dependencies were resolved, and true cross compilation could commence... of pure Go code.

However, there was still one feature missing: cross compiling Go code that used CGO itself, which isn't trivial since you need access to OS specific headers and libraries. This becomes very annoying when you need access only to some trivial OS specific functionality (e.g. query the CPU load), but need to configure and maintain separate build environments to do it.

Enter xgo

My solution to the challenge of cross compiling Go code with embedded C/C++ snippets (i.e. CGO_ENABLED=1) is based on the concept of lightweight Linux containers. All the necessary Go tool-chains, C cross compilers and platform headers/libraries have been assembled into a single Docker container, which can then be called as if a single command to compile a Go package to various platforms and architectures.

Installation

Although you could build the container manually, it is available as an automatic trusted build from Docker's container registry (not insignificant in size):

docker pull karalabe/xgo-latest

To prevent having to remember a potentially complex Docker command every time, a lightweight Go wrapper was written on top of it.

go get github.com/karalabe/xgo

Usage

Simply specify the import path you want to build, and xgo will do the rest:

$ xgo github.com/project-iris/iris
...

$ ls -al
-rwxr-xr-x  1 root  root    9995000 Nov 24 16:44 iris-android-16-arm
-rwxr-xr-x  1 root  root    6776500 Nov 24 16:44 iris-darwin-10.6-386
-rwxr-xr-x  1 root  root    8755532 Nov 24 16:44 iris-darwin-10.6-amd64
-rwxr-xr-x  1 root  root    7114176 Nov 24 16:45 iris-ios-5.0-arm
-rwxr-xr-x  1 root  root   10135248 Nov 24 16:44 iris-linux-386
-rwxr-xr-x  1 root  root   12598472 Nov 24 16:44 iris-linux-amd64
-rwxr-xr-x  1 root  root   10040464 Nov 24 16:44 iris-linux-arm
-rwxr-xr-x  1 root  root    7516368 Nov 24 16:44 iris-windows-4.0-386.exe
-rwxr-xr-x  1 root  root    9549416 Nov 24 16:44 iris-windows-4.0-amd64.exe

If the path is not a canonical import path, but rather a local path (starts with a dot . or a dash /), xgo will use the local GOPATH contents for the cross compilation.

Build flags

A handful of flags can be passed to go build. The currently supported ones are

-v: prints the names of packages as they are compiled
-x: prints the build commands as compilation progresses
-race: enables data race detection (supported only on amd64, rest built without)
-tags='tag list': list of build tags to consider satisfied during the build
-ldflags='flag list': arguments to pass on each go tool link invocation
-buildmode=mode: binary type to produce by the compiler

Go releases

As newer versions of the language runtime, libraries and tools get released, these will get incorporated into xgo too as extensions layers to the base cross compilation image (only Go 1.3 and above will be supported).

You can select which Go release to work with through the -go command line flag to xgo and if the specific release was already integrated, it will automatically be retrieved and installed.

$ xgo -go 1.6.1 github.com/project-iris/iris

Additionally, a few wildcard release strings are also supported:

latest will use the latest Go release (this is the default)
1.6.x will use the latest point release of a specific Go version
1.6-develop will use the develop branch of a specific Go version
develop will use the develop branch of the entire Go repository

Output prefixing

xgo by default uses the name of the package being cross compiled as the output file prefix. This can be overridden with the -out flag.

$ xgo -out iris-v0.3.2 github.com/project-iris/iris
...

$ ls -al
-rwxr-xr-x  1 root  root   9995000 Nov 24 16:44 iris-v0.3.2-android-16-arm
-rwxr-xr-x  1 root  root   6776500 Nov 24 16:44 iris-v0.3.2-darwin-10.6-386
-rwxr-xr-x  1 root  root   8755532 Nov 24 16:44 iris-v0.3.2-darwin-10.6-amd64
-rwxr-xr-x  1 root  root   7114176 Nov 24 16:45 iris-v0.3.2-ios-5.0-arm
-rwxr-xr-x  1 root  root  10135248 Nov 24 16:44 iris-v0.3.2-linux-386
-rwxr-xr-x  1 root  root  12598472 Nov 24 16:44 iris-v0.3.2-linux-amd64
-rwxr-xr-x  1 root  root  10040464 Nov 24 16:44 iris-v0.3.2-linux-arm
-rwxr-xr-x  1 root  root   7516368 Nov 24 16:44 iris-v0.3.2-windows-4.0-386.exe
-rwxr-xr-x  1 root  root   9549416 Nov 24 16:44 iris-v0.3.2-windows-4.0-amd64.exe

Branch selection

Similarly to go get, xgo also uses the master branch of a repository during source code retrieval. To switch to a different branch before compilation pass the desired branch name through the --branch argument.

$ xgo --branch release-branch.go1.4 golang.org/x/tools/cmd/goimports
...

$ ls -al
-rwxr-xr-x  1 root  root   4171248 Nov 24 16:40 goimports-android-16-arm
-rwxr-xr-x  1 root  root   4139868 Nov 24 16:40 goimports-darwin-10.6-386
-rwxr-xr-x  1 root  root   5186720 Nov 24 16:40 goimports-darwin-10.6-amd64
-rwxr-xr-x  1 root  root   3202364 Nov 24 16:40 goimports-ios-5.0-arm
-rwxr-xr-x  1 root  root   4189456 Nov 24 16:40 goimports-linux-386
-rwxr-xr-x  1 root  root   5264136 Nov 24 16:40 goimports-linux-amd64
-rwxr-xr-x  1 root  root   4209416 Nov 24 16:40 goimports-linux-arm
-rwxr-xr-x  1 root  root   4348416 Nov 24 16:40 goimports-windows-4.0-386.exe
-rwxr-xr-x  1 root  root   5415424 Nov 24 16:40 goimports-windows-4.0-amd64.exe

Remote selection

Yet again similarly to go get, xgo uses the repository remote corresponding to the import path being built. To switch to a different remote while preserving the original import path, use the --remote argument.

$ xgo --remote github.com/golang/tools golang.org/x/tools/cmd/goimports
...

Package selection

If you used the above branch or remote selection machanisms, it may happen that the path you are trying to build is only present in the specific branch and not the default repository, causing Go to fail at locating it. To circumvent this, you may specify only the repository root for xgo, and use an additional --pkg parameter to select the exact package within, honoring any prior branch and remote selections.

$ xgo --pkg cmd/goimports golang.org/x/tools
...

$ ls -al
-rwxr-xr-x  1 root  root   4194956 Nov 24 16:38 goimports-android-16-arm
-rwxr-xr-x  1 root  root   4164448 Nov 24 16:38 goimports-darwin-10.6-386
-rwxr-xr-x  1 root  root   5223584 Nov 24 16:38 goimports-darwin-10.6-amd64
-rwxr-xr-x  1 root  root   3222848 Nov 24 16:39 goimports-ios-5.0-arm
-rwxr-xr-x  1 root  root   4217184 Nov 24 16:38 goimports-linux-386
-rwxr-xr-x  1 root  root   5295768 Nov 24 16:38 goimports-linux-amd64
-rwxr-xr-x  1 root  root   4233120 Nov 24 16:38 goimports-linux-arm
-rwxr-xr-x  1 root  root   4373504 Nov 24 16:38 goimports-windows-4.0-386.exe
-rwxr-xr-x  1 root  root   5450240 Nov 24 16:38 goimports-windows-4.0-amd64.exe

This argument may at some point be integrated into the import path itself, but for now it exists as an independent build parameter. Also, there is not possibility for now to build mulitple commands in one go.

Limit build targets

By default xgo will try and build the specified package to all platforms and architectures supported by the underlying Go runtime. If you wish to restrict the build to only a few target systems, use the comma separated --targets CLI argument:

--targets=linux/arm: builds only the ARMv5 Linux binaries (arm-6/arm-7 allowed)
--targets=windows/*,darwin/*: builds all Windows and OSX binaries
--targets=*/arm: builds ARM binaries for all platforms
--targets=*/*: builds all suppoted targets (default)

The supported targets are:

Platforms: android, darwin, ios, linux, windows
Achitectures: 386, amd64, arm-5, arm-6, arm-7, arm64, mips, mipsle, mips64, mips64le

Platform versions

By default xgo tries to cross compile to the lowest possible versions of every supported platform, in order to produce binaries that are portable among various versions of the same operating system. This however can lead to issues if a used dependency is only supported by more recent systems. As such, xgo supports the selection of specific platform versions by appending them to the OS target string.

--targets=ios-8.1/*: cross compile to iOS 8.1
--targets=android-16/*: cross compile to Android Jelly Bean
--targets=darwin-10.9/*: cross compile to Mac OS X Mavericks
--targets=windows-6.0/*: cross compile to Windows Vista

The supported platforms are:

All Android APIs up to Android Lollipop 5.0 (API level ids)
All Windows APIs up to Windows 8.1 limited by mingw-w64 (API level ids)
OSX APIs in the range of 10.6 - 10.11
All iOS APIs up to iOS 9.3

Mobile libraries

Apart from the usual runnable binaries, xgo also supports building library archives for Android (android/aar) and iOS (ios/framework). Opposed to gomobile however xgo does not derive library APIs from the Go code, so proper CGO C external methods must be defined within the package.

In the case of Android archives, all architectures will be bundled that are supported by the requested Android platform version. For iOS frameworks xgo will bundle armv7 and arm64 by default, and also the x86_64 simulator builds if the iPhoneSimulator.sdk was injected by the user:

Create a new docker image based on xgo: FROM karalabe/xgo-latest
Inject the simulator SDK: ADD iPhoneSimulator9.3.sdk.tar.xz /iPhoneSimulator9.3.sdk.tar.xz
Bootstrap the simulator SDK: $UPDATE_IOS /iPhoneSimulator9.3.sdk.tar.xz

CGO dependencies

The main differentiator of xgo versus other cross compilers is support for basic embedded C/C++ code and target-platform specific OS SDK availability. The current xgo release introduces an experimental CGO dependency cross compilation, enabling building Go programs that require external C/C++ libraries.

It is assumed that the dependent C/C++ library is configure/make based, was properly prepared for cross compilation and is available as a tarball download (.tar, .tar.gz or .tar.bz2). Further plans include extending this to cmake based projects, if need arises (please open an issue if it's important to you).

Such dependencies can be added via the --deps argument. They will be retrieved prior to starting the cross compilation and the packages cached to save bandwidth on subsequent calls.

A complex sample for such a scenario is building the Ethereum CLI node, which has the GNU Multiple Precision Arithmetic Library as it's dependency.

$ xgo --deps=https://gmplib.org/download/gmp/gmp-6.1.0.tar.bz2  \
    --targets=windows/* github.com/ethereum/go-ethereum/cmd/geth
...

$ ls -al
-rwxr-xr-x 1 root root 16315679 Nov 24 16:39 geth-windows-4.0-386.exe
-rwxr-xr-x 1 root root 19452036 Nov 24 16:38 geth-windows-4.0-amd64.exe

Some trivial arguments may be passed to the dependencies' configure script via --depsargs.

$ xgo --deps=https://gmplib.org/download/gmp/gmp-6.1.0.tar.bz2  \
    --targets=ios/* --depsargs=--disable-assembly               \
    github.com/ethereum/go-ethereum/cmd/geth
...

$ ls -al
-rwxr-xr-x 1 root root 14804160 Nov 24 16:32 geth-ios-5.0-arm

Note, that since xgo needs to cross compile the dependencies for each platform and architecture separately, build time can increase significantly.

xgo's People

Contributors

Stargazers

Watchers

Forkers

rainsome-org1 kdar hasty wheelcomplex godeep jnslxndr rwcarlsen dezmodue biilmann kissthink tsg dan-turner dustinblackman wernerb ethernetdan aarono wintermooch coryb kindlyops protonmail yecq mewbak davidmilberg akphyo insionng elasticlic vyrus001 tarkalabs mudesheng glycerine lubaoyilang marahin jsky1989 gowso appknox jonathanmarvens sofuture ykyuen elgatito ivilata xumeiquer cj123 lixingwang schollz artpar nucleosinc happy-ferret jonike golang-alex-alex2006hw xi1314 ibbd wormon cyysu koalacxr pjebs whatever4711 priestd09 kevinpfab bhcleek bollwarm purfree fivepente bcvery1 wiseplat mohammed90 jannson fusionfoto richardyicai admpub rawtxapp oizma ionrock mirannda avadasma acohn aquachain misselvexu mysteriumnetwork niklaskhf step7750 young21 vedhavyas uimeet status-im ryupold richardlt rizze-brasil-ltda jekkos hekbobo chainpunk onlinehead whitecandylee kolaente csstaub cjbassi noamshemesh itsfunny hotion ztencmcp manishshrestha

xgo's Issues

gx support ( for IPFS )

I am trying to cross-compile IPFS for android - unfortunately IPFS uses gx as packagemanager and this does not work well with xgo:

 xgo github.com/ipfs/go-ipfs/cmd/ipfs/
Checking docker installation...
Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.6.1
 Git commit:   20f81dd
 Built:        Wed, 20 Apr 2016 14:19:16 -0700
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.6.1
 Git commit:   20f81dd
 Built:        Wed, 20 Apr 2016 14:19:16 -0700
 OS/Arch:      linux/amd64

Checking for required docker image karalabe/xgo-latest... found.
Cross compiling github.com/ipfs/go-ipfs/cmd/ipfs/...
Fetching main repository github.com/ipfs/go-ipfs/cmd/ipfs/...
github.com/ipfs/go-ipfs (download)
package gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess: unrecognized import path "gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess" (import path does not begin with hostname)
package gx/ipfs/QmT8rehPR3F6bmwL6zjUN8XpiDBFFpMP2myPdC6ApsWfJf/go-base58: unrecognized import path "gx/ipfs/QmT8rehPR3F6bmwL6zjUN8XpiDBFFpMP2myPdC6ApsWfJf/go-base58" (import path does not begin with hostname)
package gx/ipfs/QmYf7ng2hG5XBtJA3tN34DQ2GUN5HNksEw1rLDkmr6vGku/go-multihash: unrecognized import path "gx/ipfs/QmYf7ng2hG5XBtJA3tN34DQ2GUN5HNksEw1rLDkmr6vGku/go-multihash" (import path does not begin with hostname)
package gx/ipfs/QmZNVWh8LLjAavuQ2JXuFmuYH3C11xo988vSgp7UQrTRj1/go-ipfs-util: unrecognized import path "gx/ipfs/QmZNVWh8LLjAavuQ2JXuFmuYH3C11xo988vSgp7UQrTRj1/go-ipfs-util" (import path does not begin with hostname)
package gx/ipfs/QmZy2y8t9zQH2a1b8q2ZSLKp17ATuJoCNxxyMFG5qFExpt/go-net/context: unrecognized import path "gx/ipfs/QmZy2y8t9zQH2a1b8q2ZSLKp17ATuJoCNxxyMFG5qFExpt/go-net/context" (import path does not begin with hostname)
package gx/ipfs/Qmazh5oNUVsDZTs2g59rq8aYQqwpss8tcUWQzor5sCCEuH/go-log: unrecognized import path "gx/ipfs/Qmazh5oNUVsDZTs2g59rq8aYQqwpss8tcUWQzor5sCCEuH/go-log" (import path does not begin with hostname)
package gx/ipfs/QmZ4Qi3GaRbjcx28Sme5eMH7RQjGkt8wHxt2a65oLaeFEV/gogo-protobuf/proto: unrecognized import path "gx/ipfs/QmZ4Qi3GaRbjcx28Sme5eMH7RQjGkt8wHxt2a65oLaeFEV/gogo-protobuf/proto" (import path does not begin with hostname)
package gx/ipfs/QmZwZjMVGss5rqYsJVGy18gNbkTJffFyq2x1uJ4e4p3ZAt/go-libp2p-peer: unrecognized import path "gx/ipfs/QmZwZjMVGss5rqYsJVGy18gNbkTJffFyq2x1uJ4e4p3ZAt/go-libp2p-peer" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol" (import path does not begin with hostname)
package gx/ipfs/QmZ4Qi3GaRbjcx28Sme5eMH7RQjGkt8wHxt2a65oLaeFEV/gogo-protobuf/io: unrecognized import path "gx/ipfs/QmZ4Qi3GaRbjcx28Sme5eMH7RQjGkt8wHxt2a65oLaeFEV/gogo-protobuf/io" (import path does not begin with hostname)
package gx/ipfs/QmUEUu1CM8bxBJxc3ZLojAi8evhTr4byQogWstABet79oY/go-libp2p-crypto: unrecognized import path "gx/ipfs/QmUEUu1CM8bxBJxc3ZLojAi8evhTr4byQogWstABet79oY/go-libp2p-crypto" (import path does not begin with hostname)
package gx/ipfs/QmcobAGsCjYt5DXoq9et9L8yR8er7o7Cu3DTvpaq12jYSz/go-multiaddr: unrecognized import path "gx/ipfs/QmcobAGsCjYt5DXoq9et9L8yR8er7o7Cu3DTvpaq12jYSz/go-multiaddr" (import path does not begin with hostname)
package gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess/context: unrecognized import path "gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess/context" (import path does not begin with hostname)
package gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess/periodic: unrecognized import path "gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess/periodic" (import path does not begin with hostname)
package gx/ipfs/QmZwZjMVGss5rqYsJVGy18gNbkTJffFyq2x1uJ4e4p3ZAt/go-libp2p-peer/queue: unrecognized import path "gx/ipfs/QmZwZjMVGss5rqYsJVGy18gNbkTJffFyq2x1uJ4e4p3ZAt/go-libp2p-peer/queue" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/mock: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/mock" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/test/util: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/test/util" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/discovery: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/discovery" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host/basic: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host/basic" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host/routed: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host/routed" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/metrics: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/metrics" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/swarm: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/swarm" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/swarm/addr: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/swarm/addr" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol/ping: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol/ping" (import path does not begin with hostname)
package gx/ipfs/Qme8dipKnZAChkp5Kfgj2MYYyBbzjqqPXmxQx3g9v3MoxP/multiaddr-filter: unrecognized import path "gx/ipfs/Qme8dipKnZAChkp5Kfgj2MYYyBbzjqqPXmxQx3g9v3MoxP/multiaddr-filter" (import path does not begin with hostname)
package gx/ipfs/QmTrxSBY8Wqd5aBB4MeizeSzS5xFbK8dQBrYaMsiGnCBhb/go-multiaddr-net: unrecognized import path "gx/ipfs/QmTrxSBY8Wqd5aBB4MeizeSzS5xFbK8dQBrYaMsiGnCBhb/go-multiaddr-net" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol/identify: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol/identify" (import path does not begin with hostname)
package gx/ipfs/QmdhsRK1EK2fvAz2i2SH5DEfkL6seDuyMYEsxKa9Braim3/client_golang/prometheus: unrecognized import path "gx/ipfs/QmdhsRK1EK2fvAz2i2SH5DEfkL6seDuyMYEsxKa9Braim3/client_golang/prometheus" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/conn: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/conn" (import path does not begin with hostname)
Assembling toolchain for android-16/arm...
Bootstrapping android-16/arm...
Compiling for android-16/arm...
package gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess: unrecognized import path "gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess" (import path does not begin with hostname)
package gx/ipfs/QmT8rehPR3F6bmwL6zjUN8XpiDBFFpMP2myPdC6ApsWfJf/go-base58: unrecognized import path "gx/ipfs/QmT8rehPR3F6bmwL6zjUN8XpiDBFFpMP2myPdC6ApsWfJf/go-base58" (import path does not begin with hostname)
package gx/ipfs/QmYf7ng2hG5XBtJA3tN34DQ2GUN5HNksEw1rLDkmr6vGku/go-multihash: unrecognized import path "gx/ipfs/QmYf7ng2hG5XBtJA3tN34DQ2GUN5HNksEw1rLDkmr6vGku/go-multihash" (import path does not begin with hostname)
package gx/ipfs/QmZNVWh8LLjAavuQ2JXuFmuYH3C11xo988vSgp7UQrTRj1/go-ipfs-util: unrecognized import path "gx/ipfs/QmZNVWh8LLjAavuQ2JXuFmuYH3C11xo988vSgp7UQrTRj1/go-ipfs-util" (import path does not begin with hostname)
package gx/ipfs/QmZy2y8t9zQH2a1b8q2ZSLKp17ATuJoCNxxyMFG5qFExpt/go-net/context: unrecognized import path "gx/ipfs/QmZy2y8t9zQH2a1b8q2ZSLKp17ATuJoCNxxyMFG5qFExpt/go-net/context" (import path does not begin with hostname)
package gx/ipfs/Qmazh5oNUVsDZTs2g59rq8aYQqwpss8tcUWQzor5sCCEuH/go-log: unrecognized import path "gx/ipfs/Qmazh5oNUVsDZTs2g59rq8aYQqwpss8tcUWQzor5sCCEuH/go-log" (import path does not begin with hostname)
package gx/ipfs/QmZ4Qi3GaRbjcx28Sme5eMH7RQjGkt8wHxt2a65oLaeFEV/gogo-protobuf/proto: unrecognized import path "gx/ipfs/QmZ4Qi3GaRbjcx28Sme5eMH7RQjGkt8wHxt2a65oLaeFEV/gogo-protobuf/proto" (import path does not begin with hostname)
package gx/ipfs/QmZwZjMVGss5rqYsJVGy18gNbkTJffFyq2x1uJ4e4p3ZAt/go-libp2p-peer: unrecognized import path "gx/ipfs/QmZwZjMVGss5rqYsJVGy18gNbkTJffFyq2x1uJ4e4p3ZAt/go-libp2p-peer" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol" (import path does not begin with hostname)
package gx/ipfs/QmZ4Qi3GaRbjcx28Sme5eMH7RQjGkt8wHxt2a65oLaeFEV/gogo-protobuf/io: unrecognized import path "gx/ipfs/QmZ4Qi3GaRbjcx28Sme5eMH7RQjGkt8wHxt2a65oLaeFEV/gogo-protobuf/io" (import path does not begin with hostname)
package gx/ipfs/QmUEUu1CM8bxBJxc3ZLojAi8evhTr4byQogWstABet79oY/go-libp2p-crypto: unrecognized import path "gx/ipfs/QmUEUu1CM8bxBJxc3ZLojAi8evhTr4byQogWstABet79oY/go-libp2p-crypto" (import path does not begin with hostname)
package gx/ipfs/QmcobAGsCjYt5DXoq9et9L8yR8er7o7Cu3DTvpaq12jYSz/go-multiaddr: unrecognized import path "gx/ipfs/QmcobAGsCjYt5DXoq9et9L8yR8er7o7Cu3DTvpaq12jYSz/go-multiaddr" (import path does not begin with hostname)
package gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess/context: unrecognized import path "gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess/context" (import path does not begin with hostname)
package gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess/periodic: unrecognized import path "gx/ipfs/QmQopLATEYMNg7dVqZRNDfeE2S1yKy8zrRh5xnYiuqeZBn/goprocess/periodic" (import path does not begin with hostname)
package gx/ipfs/QmZwZjMVGss5rqYsJVGy18gNbkTJffFyq2x1uJ4e4p3ZAt/go-libp2p-peer/queue: unrecognized import path "gx/ipfs/QmZwZjMVGss5rqYsJVGy18gNbkTJffFyq2x1uJ4e4p3ZAt/go-libp2p-peer/queue" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/mock: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/mock" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/test/util: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/test/util" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/discovery: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/discovery" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host/basic: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host/basic" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host/routed: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/host/routed" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/metrics: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/metrics" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/swarm: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/swarm" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/swarm/addr: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/swarm/addr" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol/ping: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol/ping" (import path does not begin with hostname)
package gx/ipfs/Qme8dipKnZAChkp5Kfgj2MYYyBbzjqqPXmxQx3g9v3MoxP/multiaddr-filter: unrecognized import path "gx/ipfs/Qme8dipKnZAChkp5Kfgj2MYYyBbzjqqPXmxQx3g9v3MoxP/multiaddr-filter" (import path does not begin with hostname)
package gx/ipfs/QmTrxSBY8Wqd5aBB4MeizeSzS5xFbK8dQBrYaMsiGnCBhb/go-multiaddr-net: unrecognized import path "gx/ipfs/QmTrxSBY8Wqd5aBB4MeizeSzS5xFbK8dQBrYaMsiGnCBhb/go-multiaddr-net" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol/identify: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/protocol/identify" (import path does not begin with hostname)
package gx/ipfs/QmdhsRK1EK2fvAz2i2SH5DEfkL6seDuyMYEsxKa9Braim3/client_golang/prometheus: unrecognized import path "gx/ipfs/QmdhsRK1EK2fvAz2i2SH5DEfkL6seDuyMYEsxKa9Braim3/client_golang/prometheus" (import path does not begin with hostname)
package gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/conn: unrecognized import path "gx/ipfs/QmXDvxcXUYn2DDnGKJwdQPxkJgG83jBTp5UmmNzeHzqbj5/go-libp2p/p2p/net/conn" (import path does not begin with hostname)
2016/05/02 17:55:30 Failed to cross compile package: exit status 1.

Missing symbols when cross compiling for windows

Update: there appears to be a bug upstream (in mingw-w64) https://sourceforge.net/p/mingw-w64/bugs/535/.

Currently, it appears that the cgo linker option -Wl,-unresolved-symbols=ignore-all isn't behaving correctly.

Swig 3.0.6

As of Go 1.5 .swig and .swigcxx requires Swig 3.0.6, more recent than what's in Ubuntu 15.10.

Support for compiling with c++ files

Go now supports compiling c++ files (as long as you write a c interface over the c++ api of course). It would be fantastic if cross platform c++ toolchains could be added to the docker image to enable doing this with xgo. It shouldn't be too difficult, but I'm not enough of a docker expert to know where things need to change. I think installing appropriate c++ compilers and adding the CXX=... for each build is about all that would be necessary.

MIPS support?

Thanks for xgo, this looks really great! I was curious if MIPS support is possible? The 1.6 release notes mentioned that linux/mips64 and linux/mips64le were now experimentally supported: https://golang.org/doc/go1.6#ports.

I was hoping to crosscompile some go programs to my router :)

Passing ldflags into the build

It would be neat to be able to add ldflags to the build by an option to the xgo binary. Specifically I'm after being able to do -ldflags="-w -X main.Version=v1.2.3".

bits/c++config.h: No such file or directory

Here's the output log. It appears some headers are expected but not available in the container.

Cross compiling github.com/wellington/wellington/wt...
Fetching main repository github.com/wellington/wellington/wt...
Fetching dependencies...
Compiling for linux/amd64...
Compiling for linux/386...
# github.com/wellington/go-libsass
In file included from /usr/include/c++/4.8/bits/stl_tree.h:61:0,
                 from /usr/include/c++/4.8/set:60,
                 from ../../go-libsass/ast.hpp:4,
                 from ../../go-libsass/ast.cpp:1:
/usr/include/c++/4.8/bits/stl_algobase.h:59:28: fatal error: bits/c++config.h: No such file or directory
 #include <bits/c++config.h>

when run compiled version in other machine I got GLIBC error

./gogs: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./gogs)

Dependency fails to extract

I am trying to use xgo to cross compile ethereum for Android, but I'm running in to some issues. I've fallen back to just trying the simplest of examples from your Readme.md and it too is failing. If I run the following:

xgo --deps=https://gmplib.org/download/gmp/gmp-6.1.0.tar.bz2  \
    --targets=windows/* github.com/ethereum/go-ethereum/cmd/geth

I get:

Checking docker installation...
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64

Checking for required docker image karalabe/xgo-latest... found.
Downloading new dependency: https://gmplib.org/download/gmp/gmp-6.1.0.tar.bz2...
New dependency cached: /var/folders/q8/x7qc7x2j01gdjyzzdskblcph0000gq/T/xgo-cache/gmp-6.1.0.tar.bz2.
Cross compiling github.com/ethereum/go-ethereum/cmd/geth...
Fetching main repository github.com/ethereum/go-ethereum/cmd/geth...
github.com/ethereum/go-ethereum (download)
cat: /deps-cache/gmp-6.1.0.tar.bz2: No such file or directory

bzip2: Compressed file ends unexpectedly;
    perhaps it is corrupted?  *Possible* reason follows.
bzip2: Inappropriate ioctl for device
    Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

tar: Child returned status 2
tar: Error is not recoverable: exiting now
2016/01/13 16:04:20 Failed to cross compile package: exit status 2.

If I run the suggested integrity test as suggested:
sudo bzip2 -tvv /var/folders/q8/x7qc7x2j01gdjyzzdskblcph0000gq/T/xgo-cache/gmp-6.1.0.tar.bz2

I get:

/var/folders/q8/x7qc7x2j01gdjyzzdskblcph0000gq/T/xgo-cache/gmp-6.1.0.tar.bz2: 
    [1: huff+mtf rt+rld]
    [2: huff+mtf rt+rld]
    [3: huff+mtf rt+rld]
    [4: huff+mtf rt+rld]
    [5: huff+mtf rt+rld]
    [6: huff+mtf rt+rld]
    [7: huff+mtf rt+rld]
    [8: huff+mtf rt+rld]
    [9: huff+mtf rt+rld]
    [10: huff+mtf rt+rld]
    [11: huff+mtf rt+rld]
    [12: huff+mtf rt+rld]
    [13: huff+mtf rt+rld]
    [14: huff+mtf rt+rld]
    [15: huff+mtf rt+rld]
    [16: huff+mtf rt+rld]
    [17: huff+mtf rt+rld]
    ok

Dependency error while cross compiling for darwin

I am trying to cross compile for darwin and I get a dependency error. My guess is because the dependency doesn't exist in the Docker image. Should I modify the docker image to install the dependency?

This is the command I am running and the missing dependency is rocksdb.
xgo -targets=darwin-10.9/386 --go=1.6.2 github.com/dgraph-io/dgraph/cmd/dgraph

Supplying rocksdb in deps flag doesn't work either because rocksdb don't have a configure script though they have a make file.

xgo -targets=darwin-10.9/386 --go=1.6.2 --deps=https://github.com/facebook/rocksdb/archive/v4.2.tar.gz github.com/dgraph-io/dgraph/cmd/dgraph

Any ideas on what could I do to make this work?

gopacket cross-compiling with xgo

Hi,
I am using https://godoc.org/github.com/google/gopacket that depends on libpcap-devel library.
How can I pass this dependency to xgo container with deps tag?
I wasn't able to find tar for libpcap-devel only rpm - https://www.rpmfind.net/linux/rpm2html/search.php?query=libpcap

For windows artifact, I guess, I will need to pass another library (Winpcap). Am I right?

http://gobuild.io now base on xgo， feel free to add link to readme.

acturally base on xgo generate a new docker image codeskyblue/gobuild3

Support for calling docker with --user

Issue:

The files created by xgo tools have root:root ownership because docker daemon runs as root.
This leads to inconvenience such as not able to clean the files without being sudo

However, it is possible to run docker process with another username/group:

docker help run 
Usage:  docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
Run a command in a new container
...
  -u, --user=                     Username or UID (format: <name|uid>[:<group|gid>])

Proposal

Add the flag user to xgo

-u, --user=                     Username or UID (format: <name|uid>[:<group|gid>])

Add this flag when calling docker

Error while building for OS X: "/usr/local/go/pkg/tool/linux_amd64/cgo: exit status 2"

Hi,
I'm encountering this problem on Debian Wheezy stable:

Checking docker installation...
Client version: 1.6.0
Client API version: 1.18
Go version (client): go1.4.2
Git commit (client): 4749651
OS/Arch (client): linux/amd64
Server version: 1.6.0
Server API version: 1.18
Go version (server): go1.4.2
Git commit (server): 4749651
OS/Arch (server): linux/amd64

Checking for required docker image karalabe/xgo-latest... found.
Cross compiling github.com/kabukky/journey...
Fetching dependencies...
Fetching github.com/kabukky/journey...
Compiling for linux/amd64...
Compiling for linux/386...
Compiling for linux/arm...
Compiling for windows/amd64...
Compiling for windows/386...
Compiling for darwin/amd64...
go build github.com/mattn/go-sqlite3: /usr/local/go/pkg/tool/linux_amd64/cgo: exit status 2
Compiling for darwin/386...
go build github.com/mattn/go-sqlite3: /usr/local/go/pkg/tool/linux_amd64/cgo: exit status 2

It worked fine in a previous version of xgo (I had to create a new VM so I installed the latest xgo version today).
The Windows and Linux binaries are compiling fine.

There is the error when using go get install package

CGO_ENABLED=0 GOOS=darwin GOARCH=amd64 go get github.com/karalabe/xgo

github.com/karalabe/xgo

runtime.cgocallbackg: nosplit stack overflow
504 assumed on entry to runtime.cgocallbackg (nosplit)
416 after runtime.cgocallbackg (nosplit) uses 88
408 on entry to runtime.exitsyscall (nosplit)
288 after runtime.exitsyscall (nosplit) uses 120
280 on entry to runtime.exitsyscallfast (nosplit)
120 after runtime.exitsyscallfast (nosplit) uses 160
112 on entry to runtime.writebarrierptr (nosplit)
64 after runtime.writebarrierptr (nosplit) uses 48
56 on entry to runtime.writebarrierptr_nostore1 (nosplit)
0 after runtime.writebarrierptr_nostore1 (nosplit) uses 56
-8 on entry to runtime.acquirem (nosplit)
reflect.typelinks: nosplit stack overflow
504 assumed on entry to reflect.typelinks (nosplit)
352 after reflect.typelinks (nosplit) uses 152
344 on entry to runtime.typedmemmove (nosplit)
320 after runtime.typedmemmove (nosplit) uses 24
312 on entry to runtime.heapBitsBulkBarrier (nosplit)
192 after runtime.heapBitsBulkBarrier (nosplit) uses 120
184 on entry to runtime.throw (nosplit)
160 after runtime.throw (nosplit) uses 24
152 on entry to runtime.dopanic (nosplit)
72 after runtime.dopanic (nosplit) uses 80
64 on entry to runtime.getcallerpc (nosplit)
56 after runtime.getcallerpc (nosplit) uses 8
48 on entry to runtime.nextBarrierPC (nosplit)
8 after runtime.nextBarrierPC (nosplit) uses 40
0 on entry to runtime.panicindex
-8 on entry to runtime.morestack (nosplit)
runtime.cgocallback_gofunc: nosplit stack overflow
504 assumed on entry to runtime.cgocallback_gofunc (nosplit)
496 after runtime.cgocallback_gofunc (nosplit) uses 8
488 on entry to runtime.cgocallbackg (nosplit)
400 after runtime.cgocallbackg (nosplit) uses 88
392 on entry to runtime.exitsyscall (nosplit)
272 after runtime.exitsyscall (nosplit) uses 120
264 on entry to runtime.exitsyscallfast (nosplit)
104 after runtime.exitsyscallfast (nosplit) uses 160
96 on entry to runtime.writebarrierptr (nosplit)
48 after runtime.writebarrierptr (nosplit) uses 48
40 on entry to runtime.writebarrierptr_nostore1 (nosplit)
-16 after runtime.writebarrierptr_nostore1 (nosplit) uses 56

Add support for GO15VENDOREXPERIMENT

In Go 1.5 the go command will read the environment variable GO15VENDOREXPERIMENT. If enabled, it will use the local "/vendor/" folder for dependencies.

Please add a command line flag that sets GO15VENDOREXPERIMENT=1 environmental variable in the build container.

need ability to specify target OSX version

See https://github.com/tpoechtrager/osxcross#deployment-target

Currently the default is 10.5 which is too old for any cgo dependency that requires c++11.

CMake support

I am trying to cross compile ui which depends on libui. The developer uses cmake to compile the project.

It would be nice if xgo could support it. I couldn't find any other solution to compile the user interface library on my machine so I can distribute binaries for all major platforms.

Handling private repositories

Is there a way to let xgo do a clone off a private repository? At the very minimum, it should export GIT_TERMINAL_PROMPT in the environment so that at least we can try to do a manual login at the prompt shown in the terminal.

Add support for building a specific branch/tag/commit

It would make the build much cleaner, instead of hoping xgo indeed fetched the right version and noone introduced a breaking commit in between.

windows: missing Secure Template Overloads

Fixed upstream: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/6ec4fb2d8c1b1abfd5aca69c382c24feb6961342/

xgo --targets=windows-6.0/amd64 --go=1.6.2 github.com/cockroachdb/cockroach
Checking docker installation...
Client:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.6.2
 Git commit:   5604cbe
 Built:        Wed Apr 27 15:27:26 UTC 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Wed Apr 27 00:34:20 2016
 OS/Arch:      linux/amd64

Cross compiling github.com/cockroachdb/cockroach...
Building locally github.com/cockroachdb/cockroach...
Compiling for windows-6.0/amd64...
# github.com/cockroachdb/c-rocksdb
In file included from internal/util/iostats_context_imp.h:7:0,
                 from ../c-rocksdb/internal_util_iostats_context.cc:8:
internal/include/rocksdb/iostats_context.h:51:42: warning: 'thread' attribute directive ignored [-Wattributes]
 extern __declspec(thread) IOStatsContext iostats_context;
                                          ^
# github.com/cockroachdb/c-rocksdb
In file included from internal/util/perf_context_imp.h:7:0,
                 from ../c-rocksdb/internal_util_perf_context.cc:8:
internal/include/rocksdb/perf_context.h:99:39: warning: 'thread' attribute directive ignored [-Wattributes]
 extern __declspec(thread) PerfContext perf_context;
                                       ^
# github.com/cockroachdb/c-rocksdb
In file included from internal/util/iostats_context_imp.h:7:0,
                 from internal/port/win/win_logger.cc:24,
                 from ../c-rocksdb/logger_platform.cpp:2:
internal/include/rocksdb/iostats_context.h:51:42: warning: 'thread' attribute directive ignored [-Wattributes]
 extern __declspec(thread) IOStatsContext iostats_context;
                                          ^
# github.com/cockroachdb/c-rocksdb
In file included from ../c-rocksdb/port_platform.cc:4:0:
internal/port/win/port_win.cc: In function 'rocksdb::port::DIR* rocksdb::port::opendir(const char*)':
internal/port/win/port_win.cc:142:73: error: invalid conversion from 'char*' to 'size_t {aka long long unsigned int}' [-fpermissive]
   strncpy_s(dir->entry_.d_name, dir->data_.name, strlen(dir->data_.name));
                                                                         ^
internal/port/win/port_win.cc:142:72: error: invalid conversion from 'size_t {aka long long unsigned int}' to 'const char*' [-fpermissive]
   strncpy_s(dir->entry_.d_name, dir->data_.name, strlen(dir->data_.name));
                                                                        ^
internal/port/win/port_win.cc:142:73: error: too few arguments to function 'errno_t strncpy_s(char*, size_t, const char*, size_t)'
   strncpy_s(dir->entry_.d_name, dir->data_.name, strlen(dir->data_.name));
                                                                         ^
In file included from /usr/share/mingw-w64/include/string.h:180:0,
                 from /usr/share/mingw-w64/include/guiddef.h:148,
                 from /usr/share/mingw-w64/include/winnt.h:628,
                 from /usr/share/mingw-w64/include/minwindef.h:163,
                 from /usr/share/mingw-w64/include/windef.h:8,
                 from /usr/share/mingw-w64/include/windows.h:69,
                 from internal/port/win/port_win.h:24,
                 from internal/port/win/port_win.cc:14,
                 from ../c-rocksdb/port_platform.cc:4:
/usr/share/mingw-w64/include/sec_api/string_s.h:30:27: note: declared here
   _CRTIMP errno_t __cdecl strncpy_s(char *_Dst,size_t _DstSizeInChars,const char *_Src,size_t _MaxCount);
                           ^
In file included from ../c-rocksdb/port_platform.cc:4:0:
internal/port/win/port_win.cc: In function 'rocksdb::port::dirent* rocksdb::port::readdir(rocksdb::port::DIR*)':
internal/port/win/port_win.cc:164:76: error: invalid conversion from 'char*' to 'size_t {aka long long unsigned int}' [-fpermissive]
   strncpy_s(dirp->entry_.d_name, dirp->data_.name, strlen(dirp->data_.name));
                                                                            ^
internal/port/win/port_win.cc:164:75: error: invalid conversion from 'size_t {aka long long unsigned int}' to 'const char*' [-fpermissive]
   strncpy_s(dirp->entry_.d_name, dirp->data_.name, strlen(dirp->data_.name));
                                                                           ^
internal/port/win/port_win.cc:164:76: error: too few arguments to function 'errno_t strncpy_s(char*, size_t, const char*, size_t)'
   strncpy_s(dirp->entry_.d_name, dirp->data_.name, strlen(dirp->data_.name));
                                                                            ^
In file included from /usr/share/mingw-w64/include/string.h:180:0,
                 from /usr/share/mingw-w64/include/guiddef.h:148,
                 from /usr/share/mingw-w64/include/winnt.h:628,
                 from /usr/share/mingw-w64/include/minwindef.h:163,
                 from /usr/share/mingw-w64/include/windef.h:8,
                 from /usr/share/mingw-w64/include/windows.h:69,
                 from internal/port/win/port_win.h:24,
                 from internal/port/win/port_win.cc:14,
                 from ../c-rocksdb/port_platform.cc:4:
/usr/share/mingw-w64/include/sec_api/string_s.h:30:27: note: declared here
   _CRTIMP errno_t __cdecl strncpy_s(char *_Dst,size_t _DstSizeInChars,const char *_Src,size_t _MaxCount);
                           ^
2016/05/26 15:19:18 Failed to cross compile package: exit status 2.

packaged OS X SDK is ancient

See: https://github.com/karalabe/xgo/blob/master/docker/base/Dockerfile#L32

This SDK version doesn't support c++11 features. Can it be updated? preferably to 10.11?

Building fails with no errors

Hi,

Currently trying to build my Golang program which can be found here so I can distribute binaries without making VMs to cross-compile. I've installed the Docker Toolkit on my MacBook Pro (OSX 10.11.4) and got the Docker image downloaded. However, when I try to compile my program, it appears that everything works fine as there are no errors. When I inspect the Darwin builds they seem to have text in them:

!<arch>
__.PKGDEF       0           0     0     644     108       `
go object darwin amd64 go1.6 X:none
build id "b349f3108598f995f677263a00b751e7d64cc27f"

$$
package dca

$$
_go_.o          0           0     0     644     57        `
go object darwin amd64 go1.6 X:none

!

These are the xgo options I am using:

xgo \
    -out builds/dca-v0.1.0 \
    --targets=darwin/*,linux/*,windows/* \
    --deps=http://downloads.xiph.org/releases/opus/opus-1.1.2.tar.gz \
    github.com/uniquoooo/dca

Any ideas?

Linking fails with "multiple definitions of ..." error when compiling for Android ARM

As per the conversation on Ethereum's gitter, when trying to compiling go-ethereum for Android ARM it fails with several, "multiple definitions of...", errors:

https://gitter.im/ethereum/go-ethereum?at=5696f30ec391361d48eaf738

The latest xgo dockerfile is still go 1.3.0

The code in xgo-1.3.x still FROM karalabe/xgo-1.3.0, maybe it is time to update it to go 1.3.1

when build project github.com/dinedal/textql got error build in windows/386 platform

Using dependencies: aclocal-1.14: command not found

Running xgo with the --deps flag I get

/deps-build/proj4/missing: line 81: aclocal-1.14: command not found
WARNING: 'aclocal-1.14' is missing on your system.
         You should only need it if you modified 'acinclude.m4' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'aclocal' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
Makefile:384: recipe for target 'aclocal.m4' failed
make: *** [aclocal.m4] Error 127

Also, when there is no configure script, but there is a autogen.sh, then that could be used to generate configure.

bug: Android builds targeting Java 1.8 which is not yet supported

The following commit upgraded the docker container to use Java 1.8:
52c3aea

This has resulted in the Android .AAR files being built to target Java 1.8. Trying to then build an Android application that depends on an .AAR produced after commit 52c3ae results in the following because no current version of Android supports 1.8*:

:MyApplication:preDexDebug
Unknown source file : UNEXPECTED TOP-LEVEL EXCEPTION:
Unknown source file : java.lang.RuntimeException: Exception parsing classes
Unknown source file :   at com.android.dx.command.dexer.Main.processClass(Main.java:752)
Unknown source file :   at com.android.dx.command.dexer.Main.processFileBytes(Main.java:718)
Unknown source file :   at com.android.dx.command.dexer.Main.access$1200(Main.java:85)
Unknown source file :   at com.android.dx.command.dexer.Main$FileBytesConsumer.processFileBytes(Main.java:1645)
Unknown source file :   at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
Unknown source file :   at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
Unknown source file :   at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
Unknown source file :   at com.android.dx.command.dexer.Main.processOne(Main.java:672)
Unknown source file :   at com.android.dx.command.dexer.Main.processAllFiles(Main.java:574)
Unknown source file :   at com.android.dx.command.dexer.Main.runMonoDex(Main.java:311)
Unknown source file :   at com.android.dx.command.dexer.Main.run(Main.java:277)
Unknown source file :   at com.android.dx.command.dexer.Main.main(Main.java:245)
Unknown source file :   at com.android.dx.command.Main.main(Main.java:106)
Unknown source file : Caused by: com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000)
Unknown source file :   at com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:472)
Unknown source file :   at com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)
Unknown source file :   at com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)
Unknown source file :   at com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.java:251)
Unknown source file :   at com.android.dx.command.dexer.Main.parseClass(Main.java:764)
Unknown source file :   at com.android.dx.command.dexer.Main.access$1500(Main.java:85)
Unknown source file :   at com.android.dx.command.dexer.Main$ClassParserTask.call(Main.java:1684)
Unknown source file :   at com.android.dx.command.dexer.Main.processClass(Main.java:749)
Unknown source file :   ... 12 more
Unknown source file : 1 error; aborting

:MyApplication:preDexDebug FAILED

References:
http://android-developers.blogspot.com.au/2016/03/first-preview-of-android-n-developer.html

Figure out a way to support arm v5/6/7 non/multiarch

There is a lot of different ways to compile an arm code, the end result being architecture and distribution specific. Since it's kind of a time bomb to support only one type and hope for the best, xgo should be extended somehow to support building all arm types. However, since they are conflicting packages, these will probably need their own separate dockerfiles. So beside version specific containers, there will probably also be arm specific ones.

Something along the lines of:

xgo-1.3.3 for the official Go distributions
xgo-1.3.3-arm-v5, xgo-1.3.3-arm-v6, xgo-1.3.3-arm-v7 for ARM specific ones

Question: how to prepare libraries?

Hi. It seems very nice approach to support cgo cross compiling.

I have a question how to use external library instead of inline C code. The project(iris) described in README uses C code in comment , but the github.com/libgit2/git2go uses some external libraries (zlib, iconv, libgit2 etc) to build. How can I prepare these libraries on xgo?

thanks,

What about gox?

https://github.com/mitchellh/gox

Difference in local vs. remote builds?

Hey all,

I'm trying to build IPFS with xgo, and need to do some tweaking, however if I build from github I get different results than building locally, with the remote build it at least begins (and correctly reports the compilation bug I'm trying to fix), however locally it doesn't find the correct target. Any ideas?

Local:

/Users/ricmoo/Development/IPFS> xgo -go 1.5.1 --targets=ios-7.0/* --pkg cmd/ipfs ./go-ipfs
Checking docker installation...
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64

Checking for required docker image karalabe/xgo-1.5.1... found.
Cross compiling ....
Building locally ....
Bootstrapping ios-7.0/arm-7...
# runtime/cgo
ldid.cpp(602): _assert(): Swap(mach_header_->filetype) == MH_EXECUTE || Swap(mach_header_->filetype) == MH_DYLIB || Swap(mach_header_->filetype) == MH_BUNDLE
# net
ldid.cpp(602): _assert(): Swap(mach_header_->filetype) == MH_EXECUTE || Swap(mach_header_->filetype) == MH_DYLIB || Swap(mach_header_->filetype) == MH_BUNDLE
# os/user
ldid.cpp(602): _assert(): Swap(mach_header_->filetype) == MH_EXECUTE || Swap(mach_header_->filetype) == MH_DYLIB || Swap(mach_header_->filetype) == MH_BUNDLE
Compiling for ios-7.0/arm-7...
can't load package: package ./cmd/ipfs: open /cmd/ipfs: no such file or directory
2015/12/12 17:30:06 Failed to cross compile package: exit status 1.

Remote:

/Users/ricmoo/Development/IPFS> xgo -go 1.5.1 --targets=ios-7.0/* --pkg cmd/ipfs github.com/ipfs/go-ipfs
Checking docker installation...
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64

Checking for required docker image karalabe/xgo-1.5.1... found.
Cross compiling github.com/ipfs/go-ipfs...
Fetching main repository github.com/ipfs/go-ipfs...
github.com/ipfs/go-ipfs (download)
Bootstrapping ios-7.0/arm-7...
# runtime/cgo
ldid.cpp(602): _assert(): Swap(mach_header_->filetype) == MH_EXECUTE || Swap(mach_header_->filetype) == MH_DYLIB || Swap(mach_header_->filetype) == MH_BUNDLE
# net
ldid.cpp(602): _assert(): Swap(mach_header_->filetype) == MH_EXECUTE || Swap(mach_header_->filetype) == MH_DYLIB || Swap(mach_header_->filetype) == MH_BUNDLE
# os/user
ldid.cpp(602): _assert(): Swap(mach_header_->filetype) == MH_EXECUTE || Swap(mach_header_->filetype) == MH_DYLIB || Swap(mach_header_->filetype) == MH_BUNDLE
Compiling for ios-7.0/arm-7...
# github.com/ipfs/go-ipfs/Godeps/_workspace/src/github.com/jbenet/go-reuseport
Godeps/_workspace/src/github.com/jbenet/go-reuseport/impl_unix.go:318: undefined: poll.New
# github.com/ipfs/go-ipfs/Godeps/_workspace/src/github.com/shirou/gopsutil/disk
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:15: undefined: MntWait
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:19: undefined: Statfs_t
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:20: undefined: MntWait
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:23: undefined: MntReadOnly
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:26: undefined: MntSynchronous
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:29: undefined: MntNoExec
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:32: undefined: MntNoSuid
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:35: undefined: MntUnion
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:38: undefined: MntAsync
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:87: undefined: Statfs_t
Godeps/_workspace/src/github.com/shirou/gopsutil/disk/disk_darwin.go:38: too many errors
2015/12/12 17:31:33 Failed to cross compile package: exit status 2.

Thanks,
RicMoo

The --remote option is failing with error complaining "Please tell me who you are."

Hello,

I'm trying to use xgo to compile a fork of go-ethereum and initially hit this issue:

Command:
xgo -branch dan --targets=android-15/* github.com/dan-turner/go-ethereum/cmd/geth

Output:

Bootstrapping android-15/arm...
Compiling for android-15/arm...
package github.com/dan-turner/go-ethereum/cmd/geth
    imports github.com/ethereum/go-ethereum/internal/debug: use of internal package not allowed
package github.com/dan-turner/go-ethereum/cmd/geth
    imports github.com/ethereum/go-ethereum/internal/web3ext: use of internal package not allowed
2016/05/18 04:59:19 Failed to cross compile package: exit status 1.

I then discovered the --remote option which sounded exactly like what I needed, but there seems to be a slight bug without it complaining about a lack of git config:

Command:
xgo --remote=https://github.com/dan-turner/go-ethereum.git -branch dan --targets=android-15/* github.com/ethereum/go-ethereum/cmd/geth
Error:

Switching over to remote https://github.com/dan-turner/go-ethereum.git...
From https://github.com/dan-turner/go-ethereum
 + 8ea3c88...9e323d6 master     -> origin/master  (forced update)
 * [new branch]      dan        -> origin/dan

*** Please tell me who you are.

Run

  git config --global user.email "[email protected]"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'root@9a9f35565a35.(none)')
2016/05/18 05:04:43 Failed to cross compile package: exit status 128.

xgo does only work with the go import path

I do not see a way to give xgo just a file to compile. e.g.

xgo path/to/a/main.go

Passing build tags into the build

For cases where this enables or disables functionality, something equivalent to go build -tags foo is necessary.

Question: Using Android NDK

Hi,

I might be missing something obvious.
I checked, the container has NDK headers and libs, yet cross compiling complains about not finding them.
I can't figure out how to actually pass the include path to cgo.

root@audrius:~# xgo --targets=android-16/arm -x -v  -ldflags "-extldflags=-I/usr/local/android-ndk-r11c/platforms/android-16/arch-arm/usr/include/ -L/usr/local/android-ndk-r11c/platforms/android-16/arch-arm/usr/lib/" github.com/xlab/android-go/android

<...snip...>

Checking for required docker image karalabe/xgo-latest... found.
Cross compiling github.com/xlab/android-go/android...
Fetching main repository github.com/xlab/android-go/android...
github.com/xlab/android-go (download)
Assembling toolchain for android-16/arm...
Bootstrapping android-16/arm...
Compiling for android-16/arm...
WORK=/tmp/go-build179250653
github.com/xlab/android-go/android
mkdir -p $WORK/github.com/xlab/android-go/android/_obj/
mkdir -p $WORK/github.com/xlab/android-go/
cd /go/src/github.com/xlab/android-go/android
CGO_LDFLAGS="-fPIE" "-landroid" "-llog" "-landroid" "-llog" "-landroid" "-llog" "-landroid" "-llog" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/github.com/xlab/android-go/android/_obj/ -importpath github.com/xlab/android-go/android -- -I $WORK/github.com/xlab/android-go/android/_obj/ -fPIE android.go cgo_helpers.go const.go types.go
# github.com/xlab/android-go/android
./android.go:11:35: fatal error: android/asset_manager.h: No such file or directory
 #include <android/asset_manager.h>
                                   ^
compilation terminated.
2016/08/17 16:06:30 Failed to cross compile package: exit status 2.

I've also tried -ldflags="-I<path to ndk headers> -L<path to ndk lib>" yet that doesn't work either.

"osxcross: error: cannot find libc++ headers" when compiling for darwin-10.9/amd64

This worked (presumably) until de9b3d3 landed a few hours ago.

cockroachdb/cockroach#6030

Digest: sha256:709a6d3bbd1625e10e75352e165ecfb3207c7d87eb7113f4a7873a5589cbc8ac
Status: Downloaded newer image for karalabe/xgo-1.6:latest
2016/04/13 13:03:43 Failed to access GOPATH element /home/ubuntu/.go_workspace/src/github.com/cockroachdb/cockroach/test-binaries.f3Le: open /home/ubuntu/.go_workspace/src/github.com/cockroachdb/cockroach/test-binaries.f3Le: permission denied
Cross compiling github.com/cockroachdb/cockroach...
Building locally github.com/cockroachdb/cockroach...
Compiling for darwin-10.9/amd64...
# github.com/cockroachdb/cockroach/util
osxcross: error: cannot find libc++ headers
osxcross: error: while detecting target
# github.com/cockroachdb/cockroach/util/tracing
osxcross: error: cannot find libc++ headers
osxcross: error: while detecting target
# github.com/cockroachdb/c-snappy
osxcross: error: cannot find libc++ headers
osxcross: error: while detecting target
# github.com/cockroachdb/c-protobuf
osxcross: error: cannot find libc++ headers
osxcross: error: while detecting target
# github.com/elastic/gosigar
osxcross: error: cannot find libc++ headers
osxcross: error: while detecting target
Error deleting container: Error response from daemon: Driver btrfs failed to remove root filesystem 4276ebe92c506d407bb42469fe772c590ada6ed964de1944eb55f6a5d0813634: Failed to destroy btrfs snapshot /var/lib/docker/btrfs/subvolumes for a78b3369092bd99400355034d06dcb5aa96dbed6b738ae72cd06bb4cdcf9e5a6: operation not permitted
2016/04/13 13:04:08 Failed to cross compile package: exit status 2.

The README indicates it should work for

OSX APIs in the range of 10.6 - 10.11

which indicates that something went wrong.

windows: missing TaskDialog

Fixed in a recent mingw-w64

# github.com/andlabs/ui
../../andlabs/ui/libui_windows_amd64.a(stddialogs.cpp.obj): In function `msgbox':
/home/simon/projects/libui/windows/stddialogs.cpp:113: undefined reference to `__imp_TaskDialog'
collect2: error: ld returned 1 exit status

Problems with dependencies compilation

Hello! I met a problem that seems like the base image does not include some necessary tools required for compilation of libpcap. Error itself says:

Your operating system's lex is insufficient to compile
 libpcap.  flex is a lex replacement that has many advantages, including
 being able to compile libpcap.  For more information, see
 http://www.gnu.org/software/flex/flex.html

Thank you!

$GOPATH/pkg is not mounted in the xgo container

...preventing any reuse of previous build artefacts.

I'm not sure if you want to do something implicit like what's currently done with GOPATH/src or something explicit like passing a flag that points to the shared pkg directory on the host machine.

Either way, this would save us about 10 minutes in our CI build.

CMake Support

It would be great if dependencies using CMake were supported.

I would like to crosscompile git2go, which has libgit2 (which uses CMake) as a dependency.

Does this support external C files?

If you look at my sample cgo repo, https://github.com/pksunkara/cbind, I have some C++ files in parser folder.

I know xgo doesn't support external libraries but Does xgo support such kind of stuff?

provided clang is old

See tpoechtrager/osxcross#53; the clang version provided by ubuntu 14.04 appears to be < 3.5, which is quite old now.

EDIT: this refers to the clang used at bootstrapping (which is also used when targeting darwin, it seems).

mips / readme

I think xgo is trying to build some mips versions when I pass linux/* but there is no mention of mips on the readme. Please can you update the readme?

Any way to build private repositories

For go projects that are private on the git server (github, bitbucket, etc...). Right now you will just get a 403 Forbidden error when the Docker image tries to pull down the repo.

Is there any way we can add support for private repos easily?

Version docker images and use git tags

Right now you have a separate docker image per go version. Unfortunately the images themselves are not versioned and all use the latest tag.

It would be nice to have a project level semver that is applied to all images, so one can chose a specific version of an image in the past and if it works be confident that it will never break in the future.

I encountered this because my cross compilation system (using xgo) suddenly broke with your latest releases, due to some obscure assembly error when compiling libwinhttp. Since there's only a latest, I'm unable to revert back to an older version of xgo at a given tag.

I think this would make xgo more reliable and production friendly.

I know a lot of people don't tag their docker images with versions or use semver, which is a shame.

GOPATH incorrect in docker base file

ENV GOPATH /go

should be

ENV GOPATH /usr/local/go

“Failed to cross compile package: exit status 132”

I’m running OS X 10.10.2 with a clean xgo installation. When I try to compile this simple project I get an error:

$ xgo github.com/bdesham/go-test
Checking docker installation...
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.4.1
Git commit (client): a8a31ef
OS/Arch (client): darwin/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.4.1
Git commit (server): a8a31ef

Checking for required docker image karalabe/xgo-latest... found.
Cross compiling github.com/bdesham/go-test...
Fetching github.com/bdesham/go-test...
Compiling for linux/amd64...
Compiling for linux/386...
Compiling for linux/arm...
Compiling for windows/amd64...
Compiling for windows/386...
Compiling for darwin/amd64...
2015/04/07 09:57:48 Failed to cross compile package: exit status 132.

Any idea what’s wrong? No files are created in the directory where I’m running this.

(My computer is a Core i7, if that matters.)

osx: compilation fails with linker error

Another one from cockroachdb:

xgo --go=1.5.1 --targets=darwin-10.9/amd64 .
Checking docker installation...
Client:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 02:49:29 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 02:49:29 UTC 2015
 OS/Arch:      linux/amd64

Checking for required docker image karalabe/xgo-1.5.1... found.
Cross compiling github.com/cockroachdb/cockroach...
Building locally github.com/cockroachdb/cockroach...
Compiling for darwin-10.9/amd64...
# github.com/cockroachdb/cockroach
/usr/local/go/pkg/tool/linux_amd64/link: running o64-clang++ failed: exit status 1
ld: warning: option -s is obsolete and being ignored
ld: internal error: atom not found in symbolIndex(__ZN6snappy17SnappyArrayWriter14AppendFromSelfEmm) for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

2015/11/03 15:04:18 Failed to cross compile package: exit status 2.

FWIW, we do all our development on OS X, so it does work natively (i.e. not via xgo).

Picking libc -- glibc, musl, bionic, eglibc

glibc is used in most desktop and server linux distributions
musl is used in small-footprint distributions, e.g. for containers (Alpine) or embedded devices (LEDE/OpenWrt)
bionic is used by Android (nothing needs to be done here, the android NDK takes care of it)
eglibc is simply a smaller version of glibc (this one really isn't that popular I think)

The most important one here is being able to build against musl. What currently happens if you e.g. run a glibc-based binary in Alpine, is that it refuses to run at all because it expects a glibc-based ld command.

@karalabe do you have any thoughts right off the bat? I can look into it sometime soon.