Go version = windows/386 after cross compiling on amd64

[michael...@googlemail.com]

After installing Go 1.3 on my windows 7 machine (amd64), a strange effect occurs after cross compiling to linux, both with the msi-installer and the zip file. The same happens with Go version 1.2.2. Here is what I am doing:

After a fresh installation, everything is as expected:

C:\go\src> go version
go version go1.3 windows/amd64

Then I set the environment variables to linux:

C:\go\src> $env:GOOS="linux"
C:\go\src> $env:GOARCH="amd64" (setting GOARCH or not had no effect)

Then I (re-)compile with:

C:\go\src> .\make.bat
# Building C bootstrap tool.
cmd/dist

# Building compilers and Go bootstrap tool.
lib9
...

The result is:

Installed Go for linux/amd64 in C:\go
Installed commands in C:\go\bin

Then the output of go version is:

go version go1.3 windows/386

and the binaries in C:\go\bin are 32-bit.

If I try to get back my amd64-installation with...

C:\go\src> $env:GOARCH="amd64"
C:\go\src> $env:GOOS="windows"
C:\go\src> .\make.bat

the amd64 binaries are in C:\go\bin\windows_amd64 and in C:\go\bin there are the 32-bit versions. The go version is still go1.3 windows/386.

I tried several things, but in every case my installation ends up as windows/386. Can anybody tell me what I'm doing wrong? I never had this problem with prior installations of Go and I don't know what I might have done differently.

Michael

[brainman]

I cannot reproduce your problem. Here is my transcript:

C:\>mkdir a

C:\>cd a

C:\a>hg clone c:\go go

updating to branch default

4210 files updated, 0 files merged, 0 files removed, 0 files unresolved

C:\a>cd go

C:\a\go>hg up -r go1.3

252 files updated, 0 files merged, 52 files removed, 0 files unresolved

C:\a\go>hg st

C:\a\go>hg par

changeset:   20189:9895f9e36435

branch:      release-branch.go1.3

tag:         go1.3

tag:         release

user:        Andrew Gerrand <a...@golang.org>

date:        Thu Jun 19 10:20:01 2014 +1000

summary:     go1.3

C:\a\go>go

'go' is not recognized as an internal or external command,

operable program or batch file.

C:\a\go>gcc

'gcc' is not recognized as an internal or external command,

operable program or batch file.

C:\a\go>set PATH=%PATH%;c:\mingw64\bin

C:\a\go>go

'go' is not recognized as an internal or external command,

operable program or batch file.

C:\a\go>gcc

gcc: fatal error: no input files

compilation terminated.

C:\a\go>cd src

C:\a\go\src>make

# Building C bootstrap tool.

cmd/dist

...

Installed Go for windows/amd64 in C:\a\go

Installed commands in C:\a\go\bin

C:\a\go\src>go

'go' is not recognized as an internal or external command,

operable program or batch file.

C:\a\go\src>set PATH=%PATH%;c:\a\go\bin

C:\a\go\src>go version

go version go1.3 windows/amd64

C:\a\go\src>set GOOS=linux

C:\a\go\src>set GOARCH=amd64

C:\a\go\src>make

# Building C bootstrap tool.

...

Installed Go for linux/amd64 in C:\a\go

Installed commands in C:\a\go\bin

C:\a\go\src>go version

go version go1.3 windows/amd64

Perhaps you can follow my steps to understand where your problem is. Just make sure you start with clean environment - no GO... environment variables and no go binaries in the PATH.

Alex

[michael...@googlemail.com]

I found the problem: I had both MinGW64 and MinGW32 in my PATH and the 32bit version of the gcc.exe was the one he found first. After I renamed the MinGW32 folder, everything works as expected.

If I understand it right, the "go tool dist" command auto generates the "runtime.GOARCH" constant within the go files. And I think, this was set to "386".

Brainman, thanks for your efforts! Your post pointed me to the right direction!!

[Dave Cheney]

> If I understand it right, the "go tool dist" command auto generates the
> "runtime.GOARCH" constant within the go files. And I think, this was set to
> "386".

cmd/dist uses the include headers of your system c compiler to detect
your system. This explains why when it discovered your 32bit gcc, your
go distribution defaulted to 32bit.

[michael...@googlemail.com]

Thanks for the clarification!

[Dave Cheney]

No worries. I'm glad you got to the bottom of it; it was an
interesting failure case.

On Tue, Jul 1, 2014 at 8:06 PM, <michael...@googlemail.com> wrote:
> Thanks for the clarification!
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/owJK6sh6xjw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.