It is not possible to have parallel cross compilers

[gopherbot]

by cole.mickens:

What steps will reproduce the problem?
1. Build one cross compiler.
2. Build another.
3. Attempt to use first cross compiler.

What is the expected output?
I expect to see a compiled binary for the target of the cross compiler.

What do you see instead?
One of a few different errors stemming from missing generated files that seem to be
cleaned up before each build, and thus not available for generated cross compilers after
subsequent other compiler builds.

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g/8g.

Which operating system are you using?
Linux amd64

Which revision are you using?  (hg identify)
96bd78e7d35e weekly/weekly.2012-02-22

Please provide any additional information below.

Basically, I'm using this gma_setup() and gma()
(https://github.com/colemickens/scripts/blob/master/dotfiles/_zshrc_golang) to build
cross compilers and then utilize them to build my project(s). The cross-compiler that I
build last works without error, but depending on the order I build them in, earlier
cross compilers don't work.

For example, that script currently builds linux/386, then linux/amd64, then windows/386.
The build for windows/386 completes fine, but I get the following error when building my
project for linux/386:

GOOS=linux GOARCH=386
# runtime
../../../go/src/pkg/runtime/asm_386.s:6 8a: No such file or directory: zasm_GOOS_GOARCH.h

If I change the order and build the linux/386 cross compiler last, I get the following
errors:

GOOS=windows GOARCH=386
# 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

[alexbrainman]

Comment 1:

Please, try these http://code.google.com/p/go-wiki/wiki/WindowsCrossCompiling. See if
that do for you.
Alex

Status changed to WaitingForReply.

[gopherbot]

Comment 2 by cole.mickens:

That's basically exactly what my script is doing. In fact, if you use those scripts and
do the `buildpkg windows 386` as it suggests, you will have a functioning cross compiler
for that target. If you then do `buildpkg linux 386`, you will have a functioning
linux/386 cross-compiler, but it breaks the windows/386 cross compiler in the process.
The problem stems from the fact that the cross compilers rely on some generated header
files that are cleaned up on subsequent builds and those only available for the last
generated cross compiler.

[alexbrainman]

Comment 3:

I don't see error messages you are seeing:
GOOS=windows GOARCH=386
# 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
Please, make sure you follow my script. Also are you using tip?
Alex

[gopherbot]

Comment 4 by cole.mickens:

I apologize, I understand now. I was under the impression those scripts were slightly
overkill and that re-running ./make.bash with an alternative GOOS/GOARCH would suffice.
I know realize that it's probably make.bash that is cleaning up the things I need. (It
also ends up rebuilding host tools each time which makes it much slower than it needs to
be).
Thanks, I'll just adjust my scripts to follow more closely what yours do.

[kylelemons]

Comment 5:

For what it's worth, I still think there should be some way to support this without
having to use external scripts.  Which may just mean checking those scripts in ;-).

[alexbrainman]

Comment 6:

Status changed to WorkingAsIntended.