Recent Window builds

Johann Höchtl

unread,

Mar 25, 2010, 5:59:37 AM3/25/10

to golang-nuts

I know that a Windows port of go is work in progress,
http://code.google.com/p/go/wiki/WindowsPort
however the last version dates from november 2009, since then the
langauge spec changed in significant areas and bugs have been fixed.

Anybody willing to provide a more recent build, probably on a regular
basis? Or is the current Windows port simply not yet worth "trying
out"?

Johann

MikeParr

unread,

Mar 25, 2010, 5:22:43 PM3/25/10

to golang-nuts

I messed around with the Windows port (and wrote a little IDE for it
in Dephi) . I was only able to run small single-file programs. As
you say, the version is an early one (still needs ; after statements).

Also I could not import all the libraries, or my own packages (though
I could compile them). I think there was an issue with file paths in
"...". The / symbol was not recognised as a separator, and I could
not get \\ (escaped \ ) to work.

Some libraries would import, some not. I don't know why - wondered if
capitals in names were an issue, but did not pursue it).

I did not try any concurrency stuff.

I'm sure a lot of work went into the port, but I decided to wait for a
better version (or install Linux!)

Good Luck
Mike

On Mar 25, 9:59 am, Johann Höchtl <johann.hoec...@gmail.com> wrote:
> I know that a Windows port of go is work in progress,http://code.google.com/p/go/wiki/WindowsPort

John C.

unread,

Mar 25, 2010, 5:54:51 PM3/25/10

to golang-nuts

Someone please correct me if I'm wrong, but as I understand it there
are two disjoint tasks in supporting Windows. As mentioned on the
Installing Go page, "Note that $GOARCH and $GOOS identify the target
environment, not the environment you are running on. In effect, you
are always cross-compiling."

Task 1: Support Windows as a platform on which to run the Go compiler
and build environment, independent of what runtime platform is
targeted.

Task 2: Support Windows as a runtime platform target, independent of
what environment is used to build the executable.

In other words, if I understand correctly and the "always cross-
compiling" is to be taken literally, then Task 1 is to add Windows to
the set of supported build environments, and Task 2 is to add Windows
to the set of supported execution environments, and these two tasks
are orthogonal. Of course, most people who would like to see Go
support on Windows probably want both Tasks 1 and 2 accomplished, and
would consider one without the other as mostly useless. Nevertheless
from a development effort perspective they may be cleanly separable.

Could somebody verify if this is accurate, or clarify for me if it is
not?

John C.

P.S. By the way, I am one of the many people following this list who
is very impressed with Go as a language and is rooting for its
continued progress and success, including Windows support (of both
kinds!) -- a big thank you to the Go team, Hector Chu, and all the
other contributors.

Joe Poirier

unread,

Mar 25, 2010, 7:43:37 PM3/25/10

to golang-nuts

It's possible to build the Go compiler on Windows and compile Go
source code in to an executable that'll run on Windows but you're
restricted to using only the built-in resources, i.e. no packages.
Well, actually, it is possible to build some packages-and in turn
import those packages-but it can be a bit of a pain to do.

Note that Alex B. has been actively working on some Windows port code
that'll lay the groundwork for porting packages to Windows. Not all
packages require porting but some have dependencies on packages that
will require it.

A few months back I created some MinGW builds using the Go release
source that was current at the time and posted a download link. If
there's interest I can try and build the current release and post an
updated link?

-joe

Jonathan Wright

unread,

Mar 25, 2010, 7:59:14 PM3/25/10

to Joe Poirier, golang-nuts

On Fri, Mar 26, 2010 at 12:43 PM, Joe Poirier <jdpo...@gmail.com> wrote:
>
> A few months back I created some MinGW builds using the Go release
> source that was current at the time and posted a download link. If
> there's interest I can try and build the current release and post an
> updated link?

Yes please.

The limited MinGW build is enough for small script like tools and to
have a first dabble with Go.

Jonathan.

Giles Lean

unread,

Mar 25, 2010, 8:07:36 PM3/25/10

to golang-nuts

John C. <jscroc...@gmail.com> wrote:

> Someone please correct me if I'm wrong, but as I understand
> it there are two disjoint tasks in supporting Windows. As
> mentioned on the Installing Go page, "Note that $GOARCH and
> $GOOS identify the target environment, not the environment
> you are running on. In effect, you are always
> cross-compiling."

Sorta-kinda. That's an ideal that I don't think is quite met
in practice: I think it's achieveable, but there are
assumptions here and there in the build environment that break
it. They're probably bugs and should be fixed:

With GOARCH=amd64 (which OS X supports, natch) and a newly
cloned source tree and empty $GOBIN to avoid hangover errors:

Looking at these two errors, fixing them might be as simple as
saying "When cross compiling, don't attemt to run the tests."

> Task 1: Support Windows as a platform on which to run the Go compiler
> and build environment, independent of what runtime platform is
> targeted.

Agree in principle, but there's some work to do first. I
suspect it won't be rocket science, but it will take some time
as whole tree builds aren't instant.

I'm tempted to call this "Task 0". If it's as trivial as
turning off the running of the tests, it's practically done.

Of course, updating the OS dependent files via mksyscall.sh
etc will have to be done on the native OS, but the Go
developers have been practical and committed all those
generated files.

> Task 2: Support Windows as a runtime platform target, independent of
> what environment is used to build the executable.

From what I've seen so far, the Windows port (unlike the ports
to Unix-like platforms) has had to link in libc, so you'd have
to have the relevant Windows DLLs on your build host which may
(or may not; I'm not a lawyer) be interesting in the legal
sense.

Thus the Windows tools might end up only able to be built on
Windows.

> Could somebody verify if this is accurate, or clarify for me
> if it is not?

I hope my comments are helpful.

The two most impressive cross compilation environments I've
seen are the one created for lcc (an ANSI C compiler where the
one binary could output code for any supported target) and
NetBSD, where all builds truly are cross compilation, and the
project goes so far as to create releases for its slower
platforms on nice fast modern x86 machines. ;-)

The NetBSD approach in a nutshell is to maintain portable
versions of the essential build tools, bootstrap them using
whatever the local host system provides (Cygwin has been used)
and then to use those bootstrapped tools to build the full
system up to and including creating ISO images, if desired.

FYI here's a link to the original paper on the NetBSD cross
build environment (PDF):

http://www.mewburn.net/luke/papers/build.sh.pdf

And the current (lengthy, not for casusal reading)
documentation of their build.sh script:

http://cvsweb.netbsd.org/bsdweb.cgi/src/BUILDING?rev=1.90&content-type=text/x-cvsweb-markup&only_with_tag=MAIN

Note that there is some fragility in this system: the more
alien your build host (e.g. one with a case insensitive file
system, APPLE CALL YOUR OFFICE YOU MADE A BIG GOOF) the easier
it is that some developer will break something and not notice.

Cheers,

Giles

brainman

unread,

Mar 25, 2010, 8:15:30 PM3/25/10

to golang-nuts

On Mar 26, 8:54 am, "John C." <jscrocket...@gmail.com> wrote:
> Someone please correct me if I'm wrong, ...

You are correct here. I just want to share/add my own experience here.

Ultimately, to use Go on Windows, you want:

1) windows binaries of build tools: go compiler and linker (8g and
8l);

2) all packages compiled for windows (all these *.a files that live in
$GOROOT/pkg/mingw_386/ directory)

then you could write any program that uses standard packages and build
it like that:

8g -o test.8 test.go
8l -o test.exe test.8

then you could just execute test.exe.

Well, to create windows binaries of 8g and 8l, apparently, you need to
install mingw (and others, like echo, bison and so on) on your windows
computer, then you could follow standard built process to make them.

But I do something different. It appears, that 8g and 8l, once built
for the platform you run them on, will compile your go program into
binary for any other platform. In fact, I think, they are designed to
produce whatever $GOARCH and $GOOS environment variables tells them to
produce.

So, my plan of attack is to forget about 1), and just use my linux 8g/
8l binaries, to compile all standard packages 2), and then, my own
program.

So if I have linux 386 pc, that is setup, like

export GOOS=linux
export GOARCH=386

then I build everything (8g, 8l and all packages for linux-386) for it
like that

cd $GOROOT/src
./make.bash

You will notice, that now you have linux binaries of 8g and 6l in
$GOBIN directory, and also all linux versions of packages are compiled
into $GOROOT/pkg/linux_386/ directory.

Now we will change our binary target:

export GOOS=mingw

and will try to compile all packages again, but windows versions now:

cd $GOROOT/src/pkg
make clean
./deps.bash
make install

the process will start with runtime package, and proceed further. It
will fail quickly, because not many packages are ready for windows
yet, but it will build some (you could look inside $GOROOT/pkg/
mingw_386/ directory). There might be enough to build a simple
program, that doesn't require many packages. You could build it, like
I mentioned earlier:

export GOOS=mingw # tell 8g/8l what target binary we want
8g -o test.8 test.go
8l -o test.exe test.8

copy test.exe to your windows pc and run it.

I manage to create a small program that inquiry my windows version,
like that:

package main

import (
"syscall"
)

func abort(funcname string, err int) {
panic(funcname+" failed: (", err, ") ", syscall.Errstr(err), "\n")
}

func print_version(v uint32) {
major := byte(v)
minor := uint8(v >> 8)
build := uint16(v >> 16)
print("windows version ", major, ".", minor, " (Build ", build, ")
\n")
}

func main() {
h, err := syscall.LoadLibrary("kernel32.dll")
if err != 0 {
abort("LoadLibrary", err)
}
defer syscall.FreeLibrary(h)
proc, err := syscall.GetProcAddress(h, "GetVersion")
if err != 0 {
abort("GetProcAddress", err)
}
r, _, _ := syscall.Syscall(uintptr(proc), 0, 0, 0)
print_version(uint32(r))
}

At this moment, syscall package is done, os, time and net to go. Once
this packages windows versions are implemented, the rest will build.
And then we could build pretty much anything, including gofmt, goidoc
and others.

Alex

PS: All this is my own experience, I've been wrong many times before.
I'm sure, Go team members will correct me, if I'm wrong.

Joe Poirier

unread,

Mar 25, 2010, 8:44:47 PM3/25/10

to golang-nuts

On Mar 25, 6:59 pm, Jonathan Wright <qua...@gmail.com> wrote:

> On Fri, Mar 26, 2010 at 12:43 PM, Joe Poirier <jdpoir...@gmail.com> wrote:
>
> > A few months back I created some MinGW builds using the Go release
> > source that was current at the time and posted a download link. If
> > there's interest I can try and build the current release and post an
> > updated link?
>
> Yes please.
>
> The limited MinGW build is enough for small script like tools and to
> have a first dabble with Go.
>
> Jonathan.

Watch for the download to show up within the next 24 hrs here:
http://bitbucket.org/jpoirier/go_mingw/downloads/

Although there may be limited or no packages available in the mingw
build the LoadLibrary call of Alex's syscall code opens the door for
some fun hacking, which gives access to a plethora of exported
functions.

-joe

John C.

unread,

Mar 25, 2010, 8:50:55 PM3/25/10

to golang-nuts

Giles & Alex,

Your responses were very helpful. Thank you.

John C.

Johann Höchtl

unread,

Mar 26, 2010, 3:53:05 AM3/26/10

to golang-nuts

On Mar 25, 10:54 pm, "John C." <jscrocket...@gmail.com> wrote:

>
> John C.
>
> P.S. By the way, I am one of the many people following this list who
> is very impressed with Go as a language and is rooting for its
> continued progress and success, including Windows support (of both
> kinds!) -- a big thank you to the Go team, Hector Chu, and all the
> other contributors.
>

This is a "me too", especially the recent addition of kinda-sorta-
exception handling looks very promissing for non-local "error" -
handling. And the integral support for concurrency. Now some tools to
monitor go routines and I'm definitely looking forward in a
"concurrency death-math" with erlang and haskell ...
Johann

Johann Höchtl

unread,

Mar 26, 2010, 3:57:54 AM3/26/10

to golang-nuts

On Mar 25, 10:22 pm, MikeParr <themikep...@googlemail.com> wrote:

>
> I'm sure a lot of work went into the port, but I decided to wait for a
> better version (or install Linux!)
>

I downloaded your first shot of an IDE. Congrats to what you've done
so far. Yes, as it current stands I would wait too. I browsed through
what hechtor did so far and the areas around path handling look like a
first try. I couldn't spot UNC file handling for example which I
consider a requisite for a Windows port.

I have Linux and will give it a try there too.

> Good Luck
> Mike
>

Johann

Jonathan Wright

unread,

Mar 26, 2010, 4:14:30 AM3/26/10

to Johann Höchtl, golang-nuts

> I couldn't spot UNC file handling for example which I
> consider a requisite for a Windows port.

Isn't UNC handling automatically taken care of by Windows when a UNC
path is provided where a file or directory is expected?

Jonathan.

Johann Höchtl

unread,

Mar 26, 2010, 4:51:28 AM3/26/10

to Jonathan Wright, golang-nuts

I guess so yes, as long as you take the right API routines supporting
UNC, MSDN is your friend. But there are places in the runtime where
explicitely '\' (Windows) vs '/' (Unix-like) is handled, and those
queries are likely to fail.
> Jonathan.
>

Reply all

Reply to author

Forward