Cross-compiling Windows Go on Linux

[Albert Strasheim]

Hello all

I'm looking into cross-compiling Windows Go on Linux using MinGW
included in Fedora:

http://fedoraproject.org/wiki/SIGs/MinGW

To allow cross-compiling, the ar command needs to be configurable.

I came up with the following patch, but I'm not sure if this is right
for all combinations of GOOS, GOARCH, GOHOSTARCH, etc. Some comments
on where to put in variables for ar would be appreciated.

diff -r 43470054417c src/Make.clib
--- a/src/Make.clib Sun Oct 17 22:35:55 2010 +0200
+++ b/src/Make.clib Mon Oct 18 09:10:44 2010 +0200
@@ -19,7 +19,7 @@
cp $(LIB) "$(GOROOT)/lib/$(LIB)"

$(LIB): $(OFILES)
- ar rsc $(LIB) $(OFILES)
+ $(AR) rsc $(LIB) $(OFILES)

CLEANFILES+=y.tab.[ch] y.output a.out $(LIB)

diff -r 43470054417c src/make.bash
--- a/src/make.bash Sun Oct 17 22:35:55 2010 +0200
+++ b/src/make.bash Mon Oct 18 09:10:44 2010 +0200
@@ -25,6 +25,8 @@
rm -f "$GOBIN"/quietgcc
CC=${CC:-gcc}
export CC
+AR=${AR:-ar}
+export AR
sed -e "s|@CC@|$CC|" < "$GOROOT"/src/quietgcc.bash > "$GOBIN"/
quietgcc
chmod +x "$GOBIN"/quietgcc

This allows me to build with:

AR=i686-pc-mingw32-ar GOHOSTARCH=386 CC=i686-pc-mingw32-gcc
GOOS=windows GOARCH=386 ./make.bash

The build makes it as far as 8g right now, at which point ld
segfaults. I've filed a bug here:

https://bugzilla.redhat.com/show_bug.cgi?id=643801

Regards

Albert

[Russ Cox]

This looks fine; please send a CL.

Russ

[Albert Strasheim]

Hello all

With the patch from

http://codereview.appspot.com/2515043/

applied and with the following packages from Fedora 14:

mingw32-w32api-3.14-1.fc14.noarch
mingw32-binutils-2.20.1-1.fc14.x86_64
mingw32-cpp-4.5.0-1.fc14.x86_64
mingw32-gcc-4.5.0-1.fc14.x86_64
mingw32-runtime-3.15.2-5.fc13.noarch

I can now build most of Windows Go on Linux.

Recipe:

Get Linux tools in place:
cd src
GOOS=linux GOARCH=386 ./make.bash

Fix lib9 so that runtime can link:
cd lib9
HOST_AR=i686-pc-mingw32-ar GOHOSTARCH=386 CC=i686-pc-mingw32-gcc
GOOS=windows GOARCH=386 make clean all

Fix runtime so that it doesn't try to run mkversion:
cd ../pkg/runtime
fix version.go
fix clean-local Makefile target not to delete version.go
fix mkversion Makefile target not to compile mkversion.c
fix version.go Makefile target not to overwrite version.go

Compile all the packages:
cd ..
HOST_AR=i686-pc-mingw32-ar GOHOSTARCH=386 CC=i686-pc-mingw32-gcc
GOOS=windows GOARCH=386 make -k clean all install

It seems the only bit that doesn't build at this point is libcgo.

You can also build the compilers, etc with:

HOST_AR=i686-pc-mingw32-ar GOHOSTARCH=386 CC=i686-pc-mingw32-gcc
GOOS=windows GOARCH=386 ./make.bash

It would be nice if these also got .exe extensions so that they don't
overwrite the Linux tools, which would let the build run all the way
through.

Regards,

Albert

[brainman]

On Nov 3, 2:29 am, Albert Strasheim <full...@gmail.com> wrote:
...

> It seems the only bit that doesn't build at this point is libcgo.
>

http://code.google.com/p/go/issues/detail?id=1051

Alex

[Albert Strasheim]

Hello Alex

Thanks, I'll take a look.

I just figured out that with the HOST_AR change applied, you can do:

yum install wine
rm -rf ~/.wine
WINEARCH=win32 HOST_AR=i686-pc-mingw32-ar GOHOSTARCH=386 CC=i686-pc-
mingw32-gcc GOOS=windows GOARCH=386 MAKEFLAGS=-j1 ./make.bash

Something kicks in to convince the kernel to run PE executables
through Wine.

I had to set MAKEFLAGS because running parallel makes causes Wine to
hang.

Wine complains a bit because it can't start wineboot, but this seems
like a good thing.

The only other warning from Wine is stuff like this:

fixme:msvcrt:MSVCRT__sopen : pmode 0x01b4 ignored

A complete Windows build using the Windows binaries on Linux. :-)

Next up, I'll try to run the unit tests.

Regards

Albert

[Albert Strasheim]

Hello all

On Nov 3, 10:28 am, Albert Strasheim <full...@gmail.com> wrote:
> Next up, I'll try to run the unit tests.

Found two bugs in the Wine crypto libraries:

http://bugs.winehq.org/show_bug.cgi?id=25013
http://bugs.winehq.org/show_bug.cgi?id=25014

Apart from that, there are some issues with the unit tests that use
the network, but everything else works.

Regards

Albert