Cross-compiling with the go tool

[Mostafa Hajizadeh]

I'm on a Mac, but want to deploy a binary on my Linux server. (Is that a good way to deploy a web app, after all?)

With the new tools I guess I have to export GOOS=linux and build my project with go build, but doing so produces these errors:

# runtime

../../../go/src/pkg/runtime/extern.go:135: undefined: theGoos

../../../go/src/pkg/runtime/extern.go:135: cannot use theGoos as type string in const initializer

Is there something I am doing wrong here? I'm using weekly.2012-03-04 on a Lion machine.

[minux]

To cross compile, you should use the dist tool, like this:

export GOOS=linux GOARCH=386 # or amd64

./all.bash

Then you will get a cross toolchain.

[Mostafa Hajizadeh]

Thanks for the suggestion, but now go build says this:

cannot use cgo when compiling for a different operating system

I rebuilt Go as you said and called "go tool dist bootstrap" afterwards.

On Wednesday, March 7, 2012 6:18:51 PM UTC+3:30, minux wrote:

[Norbert Roos]

> cannot use cgo when compiling for a different operating system

You can try "export CGO_ENABLED=0" (and maybe ./make.bash instead of
./all.bash).

I think this doesn't build all, so if you are using the wrong packets,
this won't help you.

Norbert

[Mostafa Hajizadeh]

Thank you very much. I finally managed to run my app on my server. :)

[Kyle Lemons]

I do this for three different servers; I develop on my mac and build (via a script, of course) with CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build $NAME -o ${NAME}_linux and then I copy it over (and the harness notices and restarts).  Works quite nicely.  Compared to my experiences trying to cross-compile with GCC, it's practically a pleasure.

[Mostafa Hajizadeh]

Yes. This is super-easy. Thanks for the confirmation.

On Wednesday, March 7, 2012 10:58:10 PM UTC+3:30, Kyle Lemons wrote:

I do this for three different servers; I develop on my mac and build (via a script, of course) with CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build $NAME -o ${NAME}_linux and then I copy it over (and the harness notices and restarts).  Works quite nicely.  Compared to my experiences trying to cross-compile with GCC, it's practically a pleasure.

[Dorival Pedroso]

what about with cgo enabled?

[minux]

On Thu, Mar 8, 2012 at 6:10 AM, Dorival Pedroso <dorival...@gmail.com> wrote:

what about with cgo enabled?

The cmd/go tool hardcode the name of gcc ('gcc', of course), and it can not be changed.

When cross compiling, this is not appropriate. But as you can't change it, you'd better disable

cgo support all together.

(I proposed adding $TARGET_CC env var to cmd/go, but got rejected.)

(If you do name your cross compiling gcc as gcc, then it is perfect valid to enable cgo

when cross compiling.)

[Kyle Lemons]

On Wed, Mar 7, 2012 at 2:10 PM, Dorival Pedroso <dorival...@gmail.com> wrote:

what about with cgo enabled?

CGO is not available for cross compiling for reasons which I don't understand well enough to summarize.  I also find that it makes a Go application somewhat less "cross platform" and so I don't use it myself.  I believe it only needs to be explicitly disabled when cross compiling something that would otherwise use CGO, i.e. something that uses the net library (which is almost everything I do).

[minux]

On Thu, Mar 8, 2012 at 6:14 AM, Kyle Lemons <kev...@google.com> wrote:

On Wed, Mar 7, 2012 at 2:10 PM, Dorival Pedroso <dorival...@gmail.com> wrote:

what about with cgo enabled?

CGO is not available for cross compiling for reasons which I don't understand well enough to summarize.  I also find that it makes a Go application somewhat less "cross platform" and so I don't use it myself.  I believe it only needs to be explicitly disabled when cross compiling something that would otherwise use CGO, i.e. something that uses the net library (which is almost everything I do).

One of the problem with cgo is that the dyanmic linker is hard coded in cmd/ld, and I plan to let cgo auto detect it

to facilitate my Linux/ARM cgo port.

Because I found some multiarch Linux distributions with non-standard dynamic linker path.

If cgo is using the right cross compiler, the libc mismatch problem (the somewhat less "cross platform" problem)

won't arise.

Of course, the general solution for this "less cross platform" problem is enable cmd/ld to do static link for required

libraries, esp. libc.

[Sanjay Menakuru]

So if you're cross compiling gcc is called "gcc", cgo will work? Unfortunately, pretty much everything I write uses net :/

If I want a distributable binary, currently, I commit, ssh, pull, go install, logout, scp

It would be nicer to go install. (Nicer still would be to have a cross compiling build server that runs on a post-commit hook, but now I may be going a bit afield...)

I'm curious how rsc did this https://code.google.com/p/codesearch/downloads/list actually. Same thing I mentioned above? or is there something smarter.

Sanjay

[minux]

On Fri, Mar 9, 2012 at 2:24 PM, Sanjay Menakuru <balas...@gmail.com> wrote:

So if you're cross compiling gcc is called "gcc", cgo will work? Unfortunately, pretty much everything I write uses net :/

I just check the source cmd/go, and the sad news is that it seems permanently disable cgo on cross compiles...