1

Summary: when I try cross-compiling a .go source file that includes a C file somewhere in the file chain, targeting Windows AMD64 from a Mac host, I get: 

/usr/local/go/src/runtime/cgo/gcc_windows_amd64.c:8:10: fatal error: 'windows.h' file not found

Purely Go code seems to cross compile without error; is there a way to get the proper header files for cross compilation when C files are involved?

More details: I installed LiteIDE on my Mac for working on some .go projects, and LiteIDE makes it relatively simple to target other platforms as build targets. I tested it on a small test project I had, purely Go, and it seemed to run without error.

Later I tried it on a current, larger project and had to adjust several env settings in the IDE to get it to work (complaints about C files without CGO enabled, and GOPATH not set properly even though it's set in .bash_profile and verified in echo $VARIABLE just fine.) The result is 

/usr/local/go/src/runtime/cgo/gcc_windows_amd64.c:8:10: fatal error: 'windows.h' file not found

Trying to target Linux (os linux, arch amd64) gives

# runtime/cgo
ld: unknown option: --build-id=none
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I've double checked I have XCode installed; gcc is installed:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr with-gxx-include-     dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1
Apple LLVM version 7.3.0 (clang-703.0.29)
Target: x86_64-apple-darwin15.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

...and Go is the latest version:

go version go1.6.2 darwin/amd64

I also checked that this isn't just from LiteIDE (since LiteIDE seems to override env settings and ignore what's in the terminal?); an example attempt at the console gives:

MyUsername$ env GOOS=windows GOARCH=amd64 CGO_ENABLED=1 go build -v
golang.org/x/net/html/atom
runtime/cgo
golang.org/x/crypto/ssh/terminal
golang.org/x/net/html
github.com/howeyc/gopass
# runtime/cgo
/usr/local/go/src/runtime/cgo/gcc_windows_amd64.c:8:10: fatal error: 'windows.h' file not found
github.com/andybalholm/cascadia
github.com/PuerkitoBio/goquery

I suspect this is because the application uses networking libraries in Go and I think the native libraries are still calling some C files to fill in gaps. Is there a way to get the proper libraries for building on Linux/Windows or does this need to be done on the target platforms in order to work?

Building native applications on the host platform seems to work without issue.

Bart Silverstrim
  • 3,445
  • 6
  • 34
  • 44
  • Your clang seems rather outdated (you don't actually have gcc btw, it's clang). – OneOfOne Apr 28 '16 at 13:28
  • @OneOfOne Checking the app store, it seems to be the latest Xcode available to me? (Doesn't Xcode include the clang compiler?) – Bart Silverstrim Apr 28 '16 at 13:32
  • I'm not 100% sure about Xcode versions, however looking at your gcc version it says 4.2.1, which is extremely outdated, but regardless, you will have to install a toolchain that can compile native C code for windows and/or Linux. If all fails, you might want to look into setting up a VM for Linux and Windows. – OneOfOne Apr 28 '16 at 13:40
  • Please consider asking your question on the [golang-nuts mailing list](https://groups.google.com/d/forum/golang-nuts) instead. – kostix Apr 28 '16 at 16:50

1 Answers1

15

To enable cross-compiling for CGO you need to have a local toolchain that can compile C code for that target.

I'm not very familiar with Mac OS X, but on Arch Linux all I had to do was install mingw-w64-toolchain and compile my go code with:

env GOOS="windows" GOARCH="386"   CGO_ENABLED="1" CC="i686-w64-mingw32-gcc"   go build
// or to target win 64
env GOOS="windows" GOARCH="amd64" CGO_ENABLED="1" CC="x86_64-w64-mingw32-gcc" go build

On OSX, you can install mingw with homebrew: brew install mingw-w64

About the other error message though, ld: unknown option: --build-id=none seems like a bug, you might want to report that on the Go issue tracker.

jmacwhyte
  • 3
  • 3
OneOfOne
  • 95,033
  • 20
  • 184
  • 185