Windows (32-bit): building the 6l\6g compiler
Joseph Poirier
building the 6g\6l compiler on a 32-bit Windows XP system. GOARCH is
set to amd64, processor architecture is x86, and I'm using tip.
Expecting
--------------
- 32-bit executables in go\bin. Got those.
- The 6* compiler, 32-bit executables, in go\pkg\tool\windows_amd64.
Got them but they're in the wrong folder (go\pkg\tool\windows_386
folder).
- The Go imports in go\pkg\windows_amd64. Got them.
- The go\pkg\obj\windows_386 folder. Got it.
Not expecting
--------------------
- The go\bin\windows_amd64 folder.
- The go\pkg\tool\windows_386 folder.
- The executables in go\pkg\tool\windows_amd64 to be 64-bit.
- The go\pkg\windows_386 folder.
It looks like GOARCH is being used to set the architecture for some of
the generated tools, and there's an extra compiler set being built
that shouldn't be. These look like bugs to me but I've been out of the
loop since X-MAS break.
Both dumpbin and file were used to check the architecture of the *.exe files.
-joe
C:\go
├───bin /* 32 bit executables */
│ │ go.exe
│ │ godoc.exe
│ │ gofmt.exe
│ │ wingui.exe
│ │
│ └───windows_amd64 /* 64 bit executables */
│ go.exe
│ godoc.exe
│ gofmt.exe
│ wingui.exe
│
└───pkg
├───obj
│ └───windows_386
│
├───tool
│ ├───windows_386 /* 32 bit executables */
│ │ 6a.exe
│ │ 6c.exe
│ │ 6g.exe
│ │ 6l.exe
│ │ 8a.exe
│ │ 8c.exe
│ │ 8g.exe
│ │ 8l.exe
│ │ api.exe
│ │ cgo.exe
│ │ cov.exe
│ │ dist.exe
│ │ ebnflint.exe
│ │ fix.exe
│ │ gotype.exe
│ │ go_bootstrap.exe
│ │ nm.exe
│ │ pack.exe
│ │ pprof
│ │ prof.exe
│ │ vet.exe
│ │ yacc.exe
│ │
│ └───windows_amd64 /* 64 bit executables */
│ api.exe
│ cgo.exe
│ ebnflint.exe
│ fix.exe
│ gotype.exe
│ vet.exe
│ yacc.exe
│
├───windows_386 /* go packages */
└───windows_amd64 /* go packages */
Russ Cox
> - 32-bit executables in go\bin. Got those.
> - The 6* compiler, 32-bit executables, in go\pkg\tool\windows_amd64.
> Got them but they're in the wrong folder (go\pkg\tool\windows_386
> folder).
They're in the right folder. In the pkg\tool tree, the directory
is named for the system that the binaries are compiled for.
These binaries are to be run on a windows_386 system.
> - The Go imports in go\pkg\windows_amd64. Got them.
> - The go\pkg\obj\windows_386 folder. Got it.
>
> Not expecting
> --------------------
> - The go\bin\windows_amd64 folder.
This exists because some windows_amd64 binaries were
generated, and we didn't want to blow away the windows_386
binaries in go\bin. If you don't want to package them, they
can be deleted.
> - The go\pkg\tool\windows_386 folder.
This exists because some tools were needed during the build
to run on your windows_386 system.
> - The executables in go\pkg\tool\windows_amd64 to be 64-bit.
They should be. Are they not?
> - The go\pkg\windows_386 folder.
Because we had to build some 386 binaries to execute during
the build (running on a 386 machine) we had to put them somewhere.
That's where they went.
We can build the eventual 64-bit Windows archive on a 64-bit
machine, which greatly simplifies things. I am not sure it is
worth worrying too much about building it on a 32-bit machine.
If you were on a 64-bit machine building a 32-bit toolset you
could set GOHOSTARCH=386 to make the build pretend you
were on a 32-bit machine. But you can't pretend in the other
direction.
Russ
brainman
I think we can simplify their life if we make both
1) 8? and 6? compilers
2) $GOROOT/pkg/windows_386/* and $GOROOT/pkg/windows_amd64/*
3) $GOROOT/pkg/tool/windows_386/* and $GOROOT/pkg/tool/windows_amd64/*
be part of either 386 or amd64 distro.
Maybe we can even go one furter, and have single windows distro for both 386 and amd64. I am not sure how to do it, because there is only one single place for go.exe - $GOROOT/bin. Perhaps, we could put 386 version of go.exe there and have two other directories $GOROOT/bin/windows_386 and $GOROOT/bin/windows_amd64 that people could use to find correct version of go.exe. Perhaps there are other issues.
Alex
minux
I feel that our windows binary distro could improve in an area of different arch support. Imagine people who need to build a particular windows arch target - 386 or amd64. At this moment we have 2 distinct windows distro 386 and amd64. Which should they download and use? What if they need to build both targets - how do they do that?
based on different GOHOSTARCH,
I think we can simplify their life if we make both
1) 8? and 6? compilers
2) $GOROOT/pkg/windows_386/* and $GOROOT/pkg/windows_amd64/*
3) $GOROOT/pkg/tool/windows_386/* and $GOROOT/pkg/tool/windows_amd64/*
be part of either 386 or amd64 distro.
(I would be very happy if the Linux version could also bundle ARM compilers and packages [with no cgo support now we don't need to worry about cross gcc])
Maybe we can even go one furter, and have single windows distro for both 386 and amd64. I am not sure how to do it, because there is only one single place for go.exe - $GOROOT/bin. Perhaps, we could put 386 version of go.exe there and have two other directories $GOROOT/bin/windows_386 and $GOROOT/bin/windows_amd64 that people could use to find correct version of go.exe. Perhaps there are other issues.
Russ Cox
That is the overwhelmingly common case, and it has the least
potential for confusion.
Thanks.
Russ
brainman
1) I have never used / seen Go before now. I would like to try it. There are 2 binary distro files 386 and amd64. Which should I pick?
386 version will work everywhere, but amd64 will not. Running amd64 go.exe on my Windows XP 32 bit system throws an error dialogue "C:\MinGW\go\bin\go.exe is not a valid Win32 application.". If I click "OK" button, the dialogue disappear, and new error message gets printed on console: "Access is denied.". So, we would have to clear this confusion before they even start downloading the distro. Most Windows users do not know the difference between 386 and amd64. Most of them wouldn't know if they are running 32 or 64 bit OS either.
2) Well, I have got this Go compiler working and built my first program. Now I am going to copy it onto our production server / give it to my friend / ..., and have it running there. Again, 386 binaries will work everywhere, but not amd64. So, if we are to supply amd64 tools, we would have to explain to our users, that some Windows computers will not be able to run them. Obviously, they will need a solution for that. Here comes 386 compiler again to the rescue, but now we would have to explain how to setup their system where both 386 and amd64 distros can coexist.
That is why I am thinking about having one single distro for Windows for both 386 and amd64 in the first place. Download it and use. Maybe have it default to 386, but provide all needed to compile amd64 binaries. All compilers and tools in amd64 binaries will be supplied too, for those wishing to use them for whatever reason.
Alex
Joseph Poirier
> On Thursday, 23 February 2012 05:32:55 UTC+11, rsc wrote:
>> Let's please just do single-system binary distributions for now.
>> That is the overwhelmingly common case, and it has the least
>> potential for confusion.
>
> "least potential for confusion" is what I want too. But I see 2 potential
> problems with 2 distros:
>
> 1) I have never used / seen Go before now. I would like to try it. There are
> 2 binary distro files 386 and amd64. Which should I pick?
>
> 386 version will work everywhere, but amd64 will not. Running amd64 go.exe
> on my Windows XP 32 bit system throws an error dialogue
> "C:\MinGW\go\bin\go.exe is not a valid Win32 application.". If I click "OK"
> button, the dialogue disappear, and new error message gets printed on
> console: "Access is denied.". So, we would have to clear this confusion
I believe there's an install target ISA flag that can be used by the
installer to prevent the installation from happening on a non-target
system.
> Most Windows users do not
> know the difference between 386 and amd64.
I think the majority understand 32-bit and 64-bit. It's simple to
enough to annotate...
>
> 2) Well, I have got this Go compiler working and built my first program. Now
> I am going to copy it onto our production server / give it to my friend /
> ..., and have it running there. Again, 386 binaries will work everywhere,
> but not amd64. So, if we are to supply amd64 tools, we would have to explain
> to our users, that some Windows computers will not be able to run them.
> Obviously, they will need a solution for that. Here comes 386 compiler again
> to the rescue, but now we would have to explain how to setup their system
> where both 386 and amd64 distros can coexist.
>
> That is why I am thinking about having one single distro for Windows for
> both 386 and amd64 in the first place. Download it and use. Maybe have it
> default to 386, but provide all needed to compile amd64 binaries. All
> compilers and tools in amd64 binaries will be supplied too, for those
> wishing to use them for whatever reason.
>
Microsoft's policy is one installer for each ISA, which is why WiX
doesn't support multiple ISA packaging.
If mixing different tool and OS ISA is a real problem, we can lock the
installer to a target ISA. And if someone really wants the 32-bit
binaries for a 64-bit system they can download the 386 zipped package,
from another location. The zip package shouldn't be a problem in that
case .
-joe
Russ Cox
> 1) I have never used / seen Go before now. I would like to try it. There are
> 2 binary distro files 386 and amd64. Which should I pick?
>
> 386 version will work everywhere, but amd64 will not. Running amd64 go.exe
> on my Windows XP 32 bit system throws an error dialogue
> "C:\MinGW\go\bin\go.exe is not a valid Win32 application.". If I click "OK"
> button, the dialogue disappear, and new error message gets printed on
> console: "Access is denied.". So, we would have to clear this confusion
> before they even start downloading the distro. Most Windows users do not
> know the difference between 386 and amd64. Most of them wouldn't know if
> they are running 32 or 64 bit OS either.
>
> 2) Well, I have got this Go compiler working and built my first program. Now
> I am going to copy it onto our production server / give it to my friend /
> ..., and have it running there. Again, 386 binaries will work everywhere,
> but not amd64. So, if we are to supply amd64 tools, we would have to explain
> to our users, that some Windows computers will not be able to run them.
> Obviously, they will need a solution for that. Here comes 386 compiler again
> to the rescue, but now we would have to explain how to setup their system
> where both 386 and amd64 distros can coexist.
>
> That is why I am thinking about having one single distro for Windows for
> both 386 and amd64 in the first place. Download it and use. Maybe have it
> default to 386, but provide all needed to compile amd64 binaries. All
> compilers and tools in amd64 binaries will be supplied too, for those
> wishing to use them for whatever reason.
This is a very complex thing to pull off well, and we do not have time to
get it right for Go 1. I think people can understand that 32-bit and 64-bit
programs are different things, especially potential developers.
Let's keep it simple for now.
Russ
brainman
That is cool.This is a very complex thing to pull off well, ..
Can we at least implement 2 of my suggestions to make both
1) 8? and 6? compilers
2) $GOROOT/pkg/windows_386/* and $GOROOT/pkg/windows_amd64/*
Alex
Russ Cox
> be part of either 386 or amd64 distro? I think, that should be fairly easy
> to implement. And it will, at least, allow people (who care) to
> cross-compile to the platform of their choice.
I want to keep things simple, and small, and that means
just one arch per zip. People who are advanced enough
to understand what cross-compiling is should have no
trouble building from source. We're not trying to cover all
developers with the binary packages, just the common cases.
There will be no Linux/arm binary download, for example.
Russ
brainman
Alex