Giter Site home page Giter Site logo

gox's Introduction

Gox - Simple Go Cross Compilation

Gox is a simple, no-frills tool for Go cross compilation that behaves a lot like standard go build. Gox will parallelize builds for multiple platforms. Gox will also build the cross-compilation toolchain for you.

Installation

To install Gox, please use go get. We tag versions so feel free to checkout that tag and compile.

$ go install github.com/mitchellh/gox@latest
...
$ gox -h
...

Usage

If you know how to use go build, then you know how to use Gox. For example, to build the current package, specify no parameters and just call gox. Gox will parallelize based on the number of CPUs you have by default and build for every platform by default:

$ gox
Number of parallel builds: 4

-->      darwin/386: github.com/mitchellh/gox
-->    darwin/amd64: github.com/mitchellh/gox
-->       linux/386: github.com/mitchellh/gox
-->     linux/amd64: github.com/mitchellh/gox
-->       linux/arm: github.com/mitchellh/gox
-->     freebsd/386: github.com/mitchellh/gox
-->   freebsd/amd64: github.com/mitchellh/gox
-->     openbsd/386: github.com/mitchellh/gox
-->   openbsd/amd64: github.com/mitchellh/gox
-->     windows/386: github.com/mitchellh/gox
-->   windows/amd64: github.com/mitchellh/gox
-->     freebsd/arm: github.com/mitchellh/gox
-->      netbsd/386: github.com/mitchellh/gox
-->    netbsd/amd64: github.com/mitchellh/gox
-->      netbsd/arm: github.com/mitchellh/gox
-->       plan9/386: github.com/mitchellh/gox

Or, if you want to build a package and sub-packages:

$ gox ./...
...

Or, if you want to build multiple distinct packages:

$ gox github.com/mitchellh/gox github.com/hashicorp/serf
...

Or if you want to just build for linux:

$ gox -os="linux"
...

Or maybe you just want to build for 64-bit linux:

$ gox -osarch="linux/amd64"
...

And more! Just run gox -h for help and additional information.

Versus Other Cross-Compile Tools

A big thanks to these other options for existing. They each paved the way in many aspects to make Go cross-compilation approachable.

  • Dave Cheney's golang-crosscompile - Gox compiles for multiple platforms and can therefore easily run on any platform Go supports, whereas Dave's scripts require a shell. Gox will also parallelize builds. Dave's scripts build sequentially. Gox has much easier to use OS/Arch filtering built in.

  • goxc - A very richly featured tool that can even do things such as build system packages, upload binaries, generate download webpages, etc. Gox is a super slim alternative that only cross-compiles binaries. Gox builds packages in parallel, whereas goxc doesn't. Gox doesn't enforce a specific output structure for built binaries.

gox's People

Contributors

alex1607 avatar briankassouf avatar cd01 avatar commitay avatar dave-tucker avatar glasser avatar gz-c avatar haraldnordgren avatar hhsnopek avatar hlandau avatar jen20 avatar mattfarina avatar mitchellh avatar mkeeler avatar mwhooker avatar ruflin avatar sethvargo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gox's Issues

"Go build runtime: (...) must be bootstrapped using make.bat" - Windows 64bits

I'm getting this error:

Number of parallel builds: 4

-->      darwin/386: github.com/hacdias/wpsync
-->    darwin/amd64: github.com/hacdias/wpsync
-->       linux/386: github.com/hacdias/wpsync
-->     linux/amd64: github.com/hacdias/wpsync
-->       linux/arm: github.com/hacdias/wpsync
-->     freebsd/386: github.com/hacdias/wpsync
-->   freebsd/amd64: github.com/hacdias/wpsync
-->     openbsd/386: github.com/hacdias/wpsync
-->   openbsd/amd64: github.com/hacdias/wpsync
-->     windows/386: github.com/hacdias/wpsync
-->   windows/amd64: github.com/hacdias/wpsync
-->     freebsd/arm: github.com/hacdias/wpsync
-->      netbsd/386: github.com/hacdias/wpsync
-->    netbsd/amd64: github.com/hacdias/wpsync
-->      netbsd/arm: github.com/hacdias/wpsync
-->       plan9/386: github.com/hacdias/wpsync

15 errors occurred:
--> darwin/amd64 error: exit status 1
Stderr: go build runtime: darwin/amd64 must be bootstrapped using make.bat

--> linux/386 error: exit status 1
Stderr: go build runtime: linux/386 must be bootstrapped using make.bat

--> linux/amd64 error: exit status 1
Stderr: go build runtime: linux/amd64 must be bootstrapped using make.bat

--> darwin/386 error: exit status 1
Stderr: go build runtime: darwin/386 must be bootstrapped using make.bat

--> linux/arm error: exit status 1
Stderr: go build runtime: linux/arm must be bootstrapped using make.bat

--> freebsd/386 error: exit status 1
Stderr: go build runtime: freebsd/386 must be bootstrapped using make.bat

--> freebsd/amd64 error: exit status 1
Stderr: go build runtime: freebsd/amd64 must be bootstrapped using make.bat

--> openbsd/386 error: exit status 1
Stderr: go build runtime: openbsd/386 must be bootstrapped using make.bat

--> openbsd/amd64 error: exit status 1
Stderr: go build runtime: openbsd/amd64 must be bootstrapped using make.bat

--> windows/386 error: exit status 1
Stderr: go build runtime: windows/386 must be bootstrapped using make.bat

--> freebsd/arm error: exit status 1
Stderr: go build runtime: freebsd/arm must be bootstrapped using make.bat

--> netbsd/386 error: exit status 1
Stderr: go build runtime: netbsd/386 must be bootstrapped using make.bat

--> netbsd/amd64 error: exit status 1
Stderr: go build runtime: netbsd/amd64 must be bootstrapped using make.bat

--> netbsd/arm error: exit status 1
Stderr: go build runtime: netbsd/arm must be bootstrapped using make.bat

--> plan9/386 error: exit status 1
Stderr: go build runtime: plan9/386 must be bootstrapped using make.bat

What should I do?

C source files not allowed when not using cgo

I don't know go at all, but I'm trying to build a project that depends on gox and having some issues getting gox to install - I'm sure I'm doing something wrong but I'm just not sure what.

I have read http://tip.golang.org/doc/go1.4#gocmd - does this mean that gox won't work with Go 1.4?

Error:

root@dev-samm:~  # go get github.com/mitchellh/gox
package github.com/mitchellh/gox
    imports runtime: C source files not allowed when not using cgo: atomic_amd64x.c defs.c float.c heapdump.c lfstack.c malloc.c mcache.c mcentral.c mem_linux.c mfixalloc.c mgc0.c mheap.c msize.c os_linux.c panic.c parfor.c proc.c runtime.c signal.c signal_amd64x.c signal_unix.c stack.c string.c sys_x86.c vdso_linux_amd64.c

Environment:

Go version: go1.4.2 linux/amd64 - Installed as per go website: tar -C /usr/local -xzf go1.4.2.linux-amd64.tar.gz

PATH=/var/lib/gems/1.8/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/go/bin
PWD=/root/go/src/github.com/xenserverarmy/packer
HOME=/root
GOROOT=/root/go
GOPATH=/usr/local/go
root@dev-samm:~  # dpkg --list | grep -i 'gcc\|libc6'
ii  gcc                                       4:4.7.2-1                     amd64        GNU C compiler
ii  gcc-4.7                                   4.7.2-5                       amd64        GNU C compiler
ii  gcc-4.7-base:amd64                        4.7.2-5                       amd64        GCC, the GNU Compiler Collection (base package)
ii  libc6:amd64                               2.13-38+deb7u7                amd64        Embedded GNU C Library: Shared libraries
ii  libc6-dev:amd64                           2.13-38+deb7u7                amd64        Embedded GNU C Library: Development Libraries and Header Files
ii  libc6-dev-i386                            2.13-38+deb7u7                amd64        Embedded GNU C Library: 32-bit development libraries for AMD64
ii  libc6-i386                                2.13-38+deb7u7                amd64        Embedded GNU C Library: 32-bit shared libraries for AMD64
ii  libgcc1:amd64                             1:4.7.2-5                     amd64        GCC support library
ii  libgomp1:amd64                            4.7.2-5                       amd64        GCC OpenMP (GOMP) support library
ii  libquadmath0:amd64                        4.7.2-5                       amd64        GCC Quad-Precision Math Library

Failing to cross-compile when using gonative with Go 1.5.1

I am using gonative and gox to cross-compile an executable using os/user. It has always been working, but it broke down when CircleCI upgraded their Golang to 1.5.1 I think. Now I am getting user: Current not implemented on darwin/amd64 from the cross-compiled executables. Any ideas what might be wrong now before I try to dive deep into Go 1.5 cross-compilation changes myself? Thanks!

different behaviour for `/...` when building symlinked directory

As normal directory:

$ gox -osarch 'linux/amd64' github.com/cloudflare/cfssl/...
Number of parallel builds: 4
-->     linux/amd64: github.com/cloudflare/cfssl
-->     linux/amd64: github.com/cloudflare/cfssl/cfssljson
-->     linux/amd64: github.com/cloudflare/cfssl/mkbundle

Now changing it to be a symlink:

$ cd src/github.com/cloudflare
$ mv cfssl _cfssl
$ ln -s _cfssl cfssl

Nothing happens with /...

$ gox -osarch 'linux/amd64' github.com/cloudflare/cfssl/...
Number of parallel builds: 4

Still works without it tho:

$ gox -osarch 'linux/amd64' github.com/cloudflare/cfssl
Number of parallel builds: 4
-->     linux/amd64: github.com/cloudflare/cfssl

build for centos 6.5 x86_64

hi, i try to build using this command : gox -osarch="linux/amd64"
building from windows 7
i want to target the centos linux 64 bit arch

i get this error message when trying to run the binary file : cannot execute binary file

  1. is building for linux is possible from windows?
  2. if yes, do i miss out anything?

gox windows not builds

C:/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat>gox
Stderr:
--> netbsd/arm error: chdir C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat: The filename, directory name, or volume label syntax is incorrect.
Stderr:
--> plan9/386 error: chdir C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat: The filename, directory name, or volume label syntax is incorrect.

I fix this with following:

file "go.go" line 58
just set to this:
chdir = packagePath[2:3] + ":" + packagePath[4:]

then rebuild gox

And All ok now:
C:/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat>gox
Number of parallel builds: 8

--> darwin/386: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> darwin/amd64: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> linux/386: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> linux/amd64: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> linux/arm: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> freebsd/386: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> freebsd/amd64: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> openbsd/386: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> openbsd/amd64: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> windows/386: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> windows/amd64: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> freebsd/arm: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> netbsd/386: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> netbsd/amd64: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> netbsd/arm: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat
--> plan9/386: /C/sync-folders/dk_sync/Projects/Sugarbowl/src/webstat

exclude files from compilation

I have a few test files in the same directory as my program. These break the binaries. it looks like gox is including them in the compilation. Is there a way to exclude these files from the compile?

Unable to specify $GOARM

This means that gox can't compile binaries for raspberry pi. The pi needs

GOOS=linux GOARCH=arm GOARM=6

It would be awesome if you could say gox -osarch="linux/arm/6" or something similar.

Local platform build is dynamic but all others are static

Eg from a recent build of rclone you can see that all these are static builds, except for the linux/amd64 build which is the platform I build on.

This seems inconsistent!

  • freebsd-386: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, not stripped
  • freebsd-amd64: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, not stripped
  • freebsd-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), statically linked, not stripped
  • linux-386: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
  • linux-amd64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
  • linux-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
  • netbsd-386: ELF 32-bit LSB executable, Intel 80386, version 1 (NetBSD), statically linked, for NetBSD 5.99, not stripped
  • netbsd-amd64: ELF 64-bit LSB executable, x86-64, version 1 (NetBSD), statically linked, for NetBSD 5.99, not stripped
  • netbsd-arm: ELF 32-bit LSB executable, ARM, version 1 (NetBSD), statically linked, for NetBSD 5.99, not stripped
  • openbsd-386: ELF 32-bit LSB executable, Intel 80386, version 1 (OpenBSD), statically linked, for OpenBSD, not stripped
  • openbsd-amd64: ELF 64-bit LSB executable, x86-64, version 1 (OpenBSD), statically linked, for OpenBSD, not stripped

Running Gox on Windows?

I am running Go 1.2.1 on the windows/386 platform.

Following the instructions in the README, I am able to build the cross-compilation toolchain. However, running Gox from the command-line generates 16 errors, one for each of the os/arch combinations. Each error says that "The system cannot find the path specified."

Am I doing something wrong?

Thanks!

Ability to use Gom instead of Go

It would be great to allow compilation via Gom instead of just Go, possibly add an option to pass in your own compile command to set this line?

I can PR this in if you'd like 😄

-build-toolchain option

Is there support for selecting what part of the toolchain you want to build.

In CI, part of the tool chain breaks during build and all I want is "linux/amd64"

ex.

$ gox -build-toolchain="linux/amd64"

Build for windows/386 platform produce an "is not valid win32 application" error

Hi to all!

i need to build gitlab-ci-multi-runner for windows/386 platform. It uses gox for the build routine.
I have a problem with windows/386 out file: "gitlab-ci-multi-runner-windows-386.exe is not valid win32 application". linux/386 out file, for example, works correctly.
Here is my steps on a blank virtual machine with Ubuntu 16.04:

apt update
apt install docker.io
apt install golang-go
export GOPATH=/home/{username}/gocode
cd $GOPATH/src
mkdir gitlab.com && cd gitlab.com
mkdir gitlab-org && cd gitlab-org
git clone https://gitlab.com/gitlab-org/gitlab-ci-multi-runner.git
cd gitlab-ci-multi-runner
make deps
cp -a $GOPATH/bin/. /usr/sbin/
make build

Sorry if this issue is unrelated this repo.

Output in uname format?

Is there any way to set the --output to something like ./bin/{{.Dir}}_{{uname -s}}_{{.uname -m}}?

I'm currently using .OS and .ARCH, but it is not in the uname format...

Impossible to build toolchain (OS X, Go 1.1.2 from Homebrew)

I can't build the toolchain using gox -build-toolchain. Here's a Gist

I'm running OS X 10.9 and Go 1.1.2 from Homebrew. I'm going to try using the official Go installer, it's probably a Homebrew-specific problem.

Edit: The official 1.1.2 installer fails without an error message, I'm going to try installing go from source.

gox doesn't display its version number

How do I know if I need to upgrade?
I can't tell what version number I have, nor what the latest version number is.
Well, I can go down and run 'git tag', and it shows the latest I have is v0.3.0. But it doesn't tell me if that's the latest version.

Build an executable from non package files

Wanted to check with you how I would build a 'main' package into multiple distributions using gox. For example, if I had a helloworld.go, and I wanted it built as an executable for all platforms using gox, how would I do it?

E.g. something like: gox helloworld.go
Right now it throws an error.
Stderr: can't load package: package : cannot find package "_" in any of $GOPATH, $GOROOT.

Support for Go 1.3?

The gox -build-toolchain command gives the following output (running under OSX 10.9):

The toolchain build can't be parallelized because compiling a single
Go source directory can only be done for one platform at a time. Therefore,
the toolchain for each platform will be built one at a time.

--> Toolchain: darwin/386
--> Toolchain: darwin/amd64
--> Toolchain: linux/386
--> Toolchain: linux/amd64
--> Toolchain: linux/arm
--> Toolchain: freebsd/386
--> Toolchain: freebsd/amd64
--> Toolchain: openbsd/386
--> Toolchain: openbsd/amd64
--> Toolchain: windows/386
--> Toolchain: windows/amd64
--> Toolchain: freebsd/arm
--> Toolchain: netbsd/386
--> Toolchain: netbsd/amd64
--> Toolchain: netbsd/arm
--> Toolchain: plan9/386

16 errors occurred:
darwin/386: Error building 'darwin/386'.

Stdout: # Building C bootstrap tool.
cmd/dist

Stderr: ld: can't open output file for writing 'cmd/dist/dist.ld_32P5tP', errno=13 for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

darwin/amd64: Error building 'darwin/amd64'.

Stdout: # Building C bootstrap tool.
cmd/dist

Stderr: ld: can't open output file for writing 'cmd/dist/dist.ld_RJ1jHq', errno=13 for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

And so on...

GOX dose not works perfectly on windows 32 bit operating systems

Dear Mitchell Hashimoto,

GOX dose not works perfectly on windows OS. My GO source code is found on F:\xProcessor directory.

When I run gox from here. I got this below error:

F:\xProcessor>gox
Number of parallel builds: 2

-->      darwin/386: _/F_/xProcessor
-->    darwin/amd64: _/F_/xProcessor
-->       linux/386: _/F_/xProcessor
-->     linux/amd64: _/F_/xProcessor
-->       linux/arm: _/F_/xProcessor
-->     freebsd/386: _/F_/xProcessor
-->   freebsd/amd64: _/F_/xProcessor
-->     openbsd/386: _/F_/xProcessor
-->   openbsd/amd64: _/F_/xProcessor
-->     windows/386: _/F_/xProcessor
-->   windows/amd64: _/F_/xProcessor
-->     freebsd/arm: _/F_/xProcessor
-->      netbsd/386: _/F_/xProcessor
-->    netbsd/amd64: _/F_/xProcessor
-->      netbsd/arm: _/F_/xProcessor
-->       plan9/386: _/F_/xProcessor

16 errors occurred:
--> darwin/386 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> darwin/amd64 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> linux/386 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> linux/arm error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> linux/amd64 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> freebsd/386 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> freebsd/amd64 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> openbsd/386 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> openbsd/amd64 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> windows/386 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> windows/amd64 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> freebsd/arm error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> netbsd/386 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> netbsd/amd64 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> netbsd/arm error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:
--> plan9/386 error: chdir /F_/xProcessor: The system cannot find the path specified.
Stderr:

Ok. When I'm cloned my project into F:\_F\xProcessor . GOX detected my project. But it raises some other errors like below:

F:\xProcessor>gox
Number of parallel builds: 2

-->      darwin/386: _/F_/xProcessor
-->    darwin/amd64: _/F_/xProcessor
-->       linux/386: _/F_/xProcessor
-->     linux/amd64: _/F_/xProcessor
-->       linux/arm: _/F_/xProcessor
-->     freebsd/386: _/F_/xProcessor
-->   freebsd/amd64: _/F_/xProcessor
-->     openbsd/386: _/F_/xProcessor
-->   openbsd/amd64: _/F_/xProcessor
-->     windows/386: _/F_/xProcessor
-->   windows/amd64: _/F_/xProcessor
-->     freebsd/arm: _/F_/xProcessor
-->      netbsd/386: _/F_/xProcessor
-->    netbsd/amd64: _/F_/xProcessor
-->      netbsd/arm: _/F_/xProcessor
-->       plan9/386: _/F_/xProcessor

15 errors occurred:
--> darwin/amd64 error: exit status 1
Stderr: go build runtime: darwin/amd64 must be bootstrapped using make.bat

--> darwin/386 error: exit status 1
Stderr: go build runtime: darwin/386 must be bootstrapped using make.bat

--> linux/386 error: exit status 1
Stderr: go build runtime: linux/386 must be bootstrapped using make.bat

--> linux/amd64 error: exit status 1
Stderr: go build runtime: linux/amd64 must be bootstrapped using make.bat

--> freebsd/386 error: exit status 1
Stderr: go build runtime: freebsd/386 must be bootstrapped using make.bat

--> linux/arm error: exit status 1
Stderr: go build runtime: linux/arm must be bootstrapped using make.bat

--> freebsd/amd64 error: exit status 1
Stderr: go build runtime: freebsd/amd64 must be bootstrapped using make.bat

--> openbsd/386 error: exit status 1
Stderr: go build runtime: openbsd/386 must be bootstrapped using make.bat

--> openbsd/amd64 error: exit status 1
Stderr: go build runtime: openbsd/amd64 must be bootstrapped using make.bat

--> windows/amd64 error: exit status 1
Stderr: go build runtime: windows/amd64 must be bootstrapped using make.bat

--> netbsd/386 error: exit status 1
Stderr: go build runtime: netbsd/386 must be bootstrapped using make.bat

--> freebsd/arm error: exit status 1
Stderr: go build runtime: freebsd/arm must be bootstrapped using make.bat

--> netbsd/amd64 error: exit status 1
Stderr: go build runtime: netbsd/amd64 must be bootstrapped using make.bat

--> netbsd/arm error: exit status 1
Stderr: go build runtime: netbsd/arm must be bootstrapped using make.bat

--> plan9/386 error: exit status 1
Stderr: go build runtime: plan9/386 must be bootstrapped using make.bat

Please help me...

Any thoughts on how I might have mis-setup golang & gox?

I've just setup golang on my OS X 10.9 machine; and have a blank $GOPATH folder.

$ go get github.com/mitchellh/gox
$ gox -h
fatal error: runtime: bsdthread_register error

runtime stack:
runtime.throw(0x235555)
    /usr/local/go/src/runtime/panic.go:491 +0xad fp=0x7fff5fbff740 sp=0x7fff5fbff710
runtime.goenvs()
    /usr/local/go/src/runtime/os_darwin.c:104 +0x70 fp=0x7fff5fbff758 sp=0x7fff5fbff740
runtime.schedinit()
    /usr/local/go/src/runtime/proc.c:141 +0x5f fp=0x7fff5fbff780 sp=0x7fff5fbff758
runtime.rt0_go(0x7fff5fbff7b0, 0x2, 0x7fff5fbff7b0, 0x0, 0x2, 0x7fff5fbff8f8, 0x7fff5fbff8fc, 0x0, 0x7fff5fbff937, 0x7fff5fbff953, ...)
    /usr/local/go/src/runtime/asm_amd64.s:95 +0x116 fp=0x7fff5fbff788 sp=0x7fff5fbff780

go get-ting other projects with binaries does not have this issue. I'm new to golang; any ideas on how to debug/resolve this? Thanks!

Add a -compress option

Most of the time I'm building Go binaries, I'm going to be zipping and tarring them up for distribution. Would you be open to adding a -compress option to automate this process? Just checking before I code it up.

GOARM propose PR

Hi

I'd like to propose a PR for working with GOARM conforming to https://github.com/golang/go/wiki/GoArm.

Because it says:

Starting from Go 1.1, the appropriate GOARM value will be chosen if you compile the program from source on the target machine. In cross compilation situations, it is recommended that you always set an appropriate GOARM value along with GOARCH.

Well, as gox deals with cross compilation it needs to deal with GOARM.

If you have interest on this please let me know and then I am going to start working on this.

Can't compile code for linux/mips64 in go1.6.2 ?

gox -osarch "linux/mips64" ./src/...
No valid platforms to build for. If you specified a value
for the 'os', 'arch', or 'osarch' flags, make sure you're
using a valid value.

However, env GOOS=linux GOARCH=mips64 go build -v xxx is useful.

warning: unable to find runtime/cgo.a

go version go1.6 darwin/amd64

» gox -os="linux darwin"                                                                                                                                                                                1 ↵
Number of parallel builds: 3

-->    darwin/arm64: github.com/xuqingfeng/mailman
-->     linux/amd64: github.com/xuqingfeng/mailman
-->     linux/ppc64: github.com/xuqingfeng/mailman
-->       linux/386: github.com/xuqingfeng/mailman
-->      darwin/386: github.com/xuqingfeng/mailman
-->   linux/ppc64le: github.com/xuqingfeng/mailman
-->    darwin/amd64: github.com/xuqingfeng/mailman
-->       linux/arm: github.com/xuqingfeng/mailman
-->     linux/arm64: github.com/xuqingfeng/mailman
-->      darwin/arm: github.com/xuqingfeng/mailman

1 errors occurred:
--> darwin/arm64 error: exit status 2
Stderr: # github.com/xuqingfeng/mailman
warning: unable to find runtime/cgo.a
/usr/local/Cellar/go/1.6/libexec/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: warning: ignoring file /var/folders/5v/5ncxhs8d7p5gjx6bmxww33vr0000gn/T/go-link-057939853/go.o, file was built for unsupported file format ( 0xCF 0xFA 0xED 0xFE 0x0C 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 ) which is not the architecture being linked (x86_64): /var/folders/5v/5ncxhs8d7p5gjx6bmxww33vr0000gn/T/go-link-057939853/go.o
Undefined symbols for architecture x86_64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any thoughts to fix this?

my go env switches arch to 386 after -build-toolchain

hi there! first, thanks for gox, i liked it much :)
issue is not directly related to gox (in my opinion) however the issue is quite sad:

  1. i have go 64-bit on my 64-bit windows7 os
  2. i run gox -build-toolchain -arch="amd64 386" -os="linux windows"
  3. go env reports my GOARCH=386 GOHOSTARCH=386 GOTOOLDIR=C:\Go\pkg\tool\windows_386
    is it a bug or feature?
    how to switch to amd64 as it was previously?

Cross compiling with 'esc'

I would like to use gox with the https://github.com/mjibson/esc package to deploy static files with my binary.

I have not been able to find a way to get the static.go file to be cross compiled into my binary though using gox.

If I run the following, everything works locally (on a mac):
$ esc -o static.go static
$ go build
$ ./myapp

But this does not work (the static files are not included in the binary):
$ esc -o static.go static
$ gox -output="bin/{{.Dir}}_{{.OS}}_{{.Arch}}" -osarch="linux/amd64 darwin/amd64"
$ cd bin && ./myapp_darwin_amd64

What am I missing? How can I get this working?

Thanks...

gox -build-toolchain - platforms failing with clang error

I am getting the following error when building the toolchain for each platform:

Stderr: ld: can't open output file for writing 'cmd/dist/dist.ld_tFtzSr', errno=13 for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
$ go version
go version go1.4 darwin/amd64

$ gox -build-toolchain
The toolchain build can't be parallelized because compiling a single
Go source directory can only be done for one platform at a time. Therefore,
the toolchain for each platform will be built one at a time.

--> Toolchain: darwin/386
--> Toolchain: darwin/amd64
--> Toolchain: linux/386
--> Toolchain: linux/amd64
--> Toolchain: linux/arm
--> Toolchain: freebsd/386
--> Toolchain: freebsd/amd64
--> Toolchain: openbsd/386
--> Toolchain: openbsd/amd64
--> Toolchain: windows/386
--> Toolchain: windows/amd64
--> Toolchain: freebsd/arm
--> Toolchain: netbsd/386
--> Toolchain: netbsd/amd64
--> Toolchain: netbsd/arm
--> Toolchain: plan9/386

16 errors occurred:
darwin/386: Error building 'darwin/386'.

Stdout: # Building C bootstrap tool.
cmd/dist


Stderr: ld: can't open output file for writing 'cmd/dist/dist.ld_tFtzSr', errno=13 for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


darwin/amd64: Error building 'darwin/amd64'.

Stdout: # Building C bootstrap tool.
cmd/dist


Stderr: ld: can't open output file for writing 'cmd/dist/dist.ld_cNqeXf', errno=13 for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


linux/386: Error building 'linux/386'.

Stdout: # Building C bootstrap tool.
cmd/dist


Stderr: ld: can't open output file for writing 'cmd/dist/dist.ld_PSYnUU', errno=13 for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


linux/amd64: Error building 'linux/amd64'.

Stdout: # Building C bootstrap tool.
cmd/dist

...

New tag?

I was looking into making a Homebrew formula for this, but noticed that the most recent tag is quite a bit older than HEAD, and Homebrew only distributes tagged releases. Any chance of getting a new tag?

GOX Refuses to Build Solaris Binaries

I specify solaris and get the following error:

$ gox --osarch="solaris/amd64"         
No valid platforms to build for. If you specified a value
for the 'os', 'arch', or 'osarch' flags, make sure you're
using a valid value.

When I run gox without specifying an operating system it does not run solaris builds. Running on an Arch Linux system with the following version:

go version go1.4.2 linux/amd64

Ability to build a single .go file

It would be a nice to give a single target go file and have it built for multiple platforms.

E.g. gox hello.go
Output: an executable in all conceivable platforms.

Nice one (from Mr goxc)

Hi Mitchell, good to see gox appear. It's a great tool and got some nice features which ought to be in goxc too (parallel builds and the templates for built artifacts is also nice), also it's good to have a tool which does one thing and one thing only.

Just one thing about your README - it states that goxc doesn't allow you to build with different versions of Go, but a few weeks ago I added that feature, with a flag -goroot=/path/to/go/root. Otherwise it just uses go like gox. So you can define which version of Go to use in your build. Otherwise your points are all valid for the time being :)

In the future if you'd like to keep in touch we could potentially keep certain features and flags consistent with one another, that might be cool.

I'm still adding more features to goxc, and soon I'll break certain features out into separate libraries before a 1.0 release - but it looks like I don't need to create a standalone cross-compiler now :)

Good work, cheers

Go 1.4 Tool Chain Setup Issue

I get the following error output when running gox --build-toolchain:

package cmd/cmd/pprof
    imports cmd/pprof/internal/driver: use of internal package not allowed
package cmd/cmd/pprof
    imports cmd/pprof/internal/fetch: use of internal package not allowed
package cmd/cmd/pprof
    imports cmd/pprof/internal/symbolizer: use of internal package not allowed
package cmd/cmd/pprof
    imports cmd/pprof/internal/symbolz: use of internal package not allowed
package cmd/cmd/pprof/internal/commands
    imports cmd/pprof/internal/report: use of internal package not allowed
package cmd/cmd/pprof/internal/commands
    imports cmd/pprof/internal/svg: use of internal package not allowed
package cmd/cmd/pprof/internal/commands
    imports cmd/pprof/internal/tempfile: use of internal package not allowed
package cmd/cmd/pprof/internal/driver
    imports cmd/pprof/internal/commands: use of internal package not allowed
package cmd/cmd/pprof/internal/driver
    imports cmd/pprof/internal/report: use of internal package not allowed
package cmd/cmd/pprof/internal/driver
    imports cmd/pprof/internal/tempfile: use of internal package not allowed
package cmd/cmd/pprof/internal/fetch
    imports cmd/pprof/internal/plugin: use of internal package not allowed
package cmd/cmd/pprof/internal/fetch
    imports cmd/pprof/internal/profile: use of internal package not allowed
package cmd/cmd/pprof/internal/plugin
    imports cmd/pprof/internal/profile: use of internal package not allowed
package cmd/cmd/pprof/internal/report
    imports cmd/pprof/internal/plugin: use of internal package not allowed
package cmd/cmd/pprof/internal/report
    imports cmd/pprof/internal/profile: use of internal package not allowed
package cmd/cmd/pprof/internal/symbolizer
    imports cmd/pprof/internal/plugin: use of internal package not allowed
package cmd/cmd/pprof/internal/symbolizer
    imports cmd/pprof/internal/profile: use of internal package not allowed
package cmd/cmd/pprof/internal/symbolz
    imports cmd/pprof/internal/profile: use of internal package not allowed

This is a case of this stackoverflow issue, and will probably be resolved (along with most of the need for gox with go 1.5. In the mean time, it makes sense sense to handle these issues.

undefined: syscall.EPIPE error goxing with osarch plan9/386 on OS X 10.10.1

I'm getting 'undefined: syscall.EPIPE' error when compiling with osarch plan9/386.
All the other osarches work fine. Any idea what could be causing this error?

> go version
go version go1.4.1 darwin/amd64

> gox -osarch="plan9/386"
Number of parallel builds: 4

-->       plan9/386: _/Users/cliffano/dev/workspace/packer-post-processor-json-updater

1 errors occurred:
--> plan9/386 error: exit status 2
Stderr: # github.com/mitchellh/packer/packer
../../go/src/github.com/mitchellh/packer/packer/ui.go:292: undefined: syscall.EPIPE

Skip vendor/

When users invoke gox ./..., please skip entries in vendor/ folders.

Workaround: gox [options] ./cmd/...

Time for a new release?

Release 0.3.0 was in 2013. There have been many changes since then (not to mention Go releases).

Time to do a new release?

gox is blind to exported GOOS and GOARCH

I've discovered that if I export GOOS and GOARCH (even to GOOS= and GOARCH=) and call gox, it will show that it build all the supported os/arch-s, but if I test results -- they will be all of one os/arch.

Cross compiling for mac

If you compile on linux you cannot use http requests in the darwin binary. It works fine when compiling from mac.

2014/06/13 16:40:42 Put https://api.spark.io/v1/devices/<secrets>?access_token=<secret>: x509: failed to load system roots and no roots provided

Any clue how to compile from linux and still be able to use http on mac?

Enabling CGO for native builds

I could easily be missing something here so please feel free to correct me, but it seems as though CGO should be enabled when building a binary for the platform you're running on even if CGO_ENABLED hasn't been set. This behaviour would then line up with Go's own build tool (source).

What is go_test.go used for?

As evidenced by e.g. commit 733261c, go_test.go needs to be updated for each Go release.

I don’t see the value which go_test.go provides. What is it useful for?

Can’t we just delete it and avoid having to update it whenever there’s a new Go release?

cgo darwin -> linux/amd64 fails

Using go1.3, cross compiling to Linux/amd64, I get a failure compiling sqlite3. Easy example case bellow:

gox -verbose -osarch linux/amd64 github.com/mattn/go-sqlite3/_example/simple
Number of parallel builds: 4

-->     linux/amd64: github.com/mattn/go-sqlite3/_example/simple

1 errors occurred:
--> linux/amd64 error: exit status 2
Stderr: # github.com/mattn/go-sqlite3
../github.com/mattn/go-sqlite3/sqlite3.c:92 unknown #: if
../github.com/mattn/go-sqlite3/sqlite3.c:94 6c: No such file or directory: mingw.h

Is this an expected failure?

From what I can find, this would be expected to work with Go 1.3:
https://code.google.com/p/go/issues/detail?id=4714

Any idea of what might be happening here?

The source is there, so I don't really understand where the error is stemming from. I'm using Go 1.3 which supposedly already support cross compiling CGO.

--> freebsd/arm error: exit status 1
Stderr: go build github.com/libgit2/git2go: no buildable Go source files in /Users/camilo/Dropbox/Development/go/src/github.com/libgit2/git2go

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.