How to build Golly on Windows

[Andrew]

This thread aims to be a tutorial for Windows programmers who would like to build Golly from source code. Hopefully this will encourage more people to get involved in the development of Golly.

WARNING: I'm *not* an expert on Windows -- I'm a Mac guy. I use Parallels to run two versions of Windows as virtual machines: a 32-bit Windows XP system and a 64-bit Windows 7 system. The only time I switch to those systems is to build and test new versions of Golly, so I'm far from a typical Windows user! Please pipe up if anything below needs to be clarified or corrected.

Enough preamble -- let's begin...

[Andrew]

Step 1: Download and install the Microsoft Windows SDK.

The recommended way to build Golly is to use the Windows SDK command line tools (eg. nmake). If you already have the Windows SDK on your system then proceed to step 2.

Before installing the Windows SDK on my Windows 7 system I first had to download an installer for the .NET Framework. I got version 4.0 from here:

https://www.microsoft.com/en-au/downloa ... x?id=17718

Then I downloaded an installer for the Microsoft Windows SDK for Windows 7 from here:

https://www.microsoft.com/en-au/downloa ... px?id=8279

If you have Windows 10 then you should probably download the SDK installer from here (it includes the .NET Framework 4.6 SDK):

https://developer.microsoft.com/en-us/w ... ows-10-sdk

After running the installer(s), go to the Start menu, open a Windows SDK Command Prompt window and type this command:

Code: Select all

setenv /release

That sets up the environment for doing a release build (which is what we'll be doing in the next steps).

[Andrew]

Step 2: Download and build wxWidgets.

Golly's code uses wxWidgets, a cross-platform C++ library for creating GUI applications, so you need to build the wxWidgets libraries.

Go to http://www.wxwidgets.org/downloads/ and download the Windows source code for the latest *stable* release (currently version 3.0.2). Make sure you download the zip file (wxWidgets-3.0.2.zip) rather than the Windows installer.

Unpack the zip file into a suitable directory like C:\wxWidgets.

Edit C:\wxWidgets\build\msw\config.vc and set these options:

Code: Select all

BUILD=release
DEBUG_INFO=0
DEBUG_FLAG=0
TARGET_CPU=X64        (if you want a 64-bit build)
RUNTIME_LIBS=static

Save your changes. Now you can go to the Windows SDK command prompt and build wxWidgets:

Code: Select all

cd C:\wxWidgets\build\msw
nmake -f makefile.vc

This will take a while. If there are no errors, proceed to the next step.

[Andrew]

Step 3: Download and install Python.

Before you can build Golly you need to have the Python headers installed somewhere on your system. You might already have them -- if you can run one of the .py scripts (eg. bricklayer.py) from an existing version of Golly then the headers should already exist.

If you don't have Python on your system then I recommend installing Python 2.7.10. Do NOT get 2.7.11; we've had reports of a problem with that version that can cause Golly to crash when you try to run a .py script.

Go to https://www.python.org/downloads/release/python-2710/ and download the appropriate installer for your system:

For 64-bit: python-2.7.10.amd64.msi
For 32-bit: python-2.7.10.msi

Run the installer and you should end up with a new directory like C:\Python27. You'll need to use that path in the next step.

[Andrew]

Step 4: Download and build Golly.

The best way to download the latest Golly source code is to use git. If you don't have git installed then I recommend downloading Git for Windows from here:

https://git-for-windows.github.io/

Then you can run the following git command:

Code: Select all

cd where\you\want\to\build\golly
git clone git://git.code.sf.net/p/golly/code golly

The last parameter is the name of the created directory and can be anything you like.

In the gui-wx subdirectory you'll see a file called local-win-template.mk. Make a copy of that file and call it local-win.mk (makefile-win will include local-win.mk). Edit local-win.mk and make any necessary changes as requested by the comments. Here is my version for building a 64-bit Golly:

Code: Select all

# Change the next 2 lines to specify where you installed wxWidgets:
!include <C:/wxWidgets/build/msw/config.vc>
WX_DIR = C:\wxWidgets

# Change the next line to match your wxWidgets version (first two digits):
WX_RELEASE = 30

LUA_DEFS = -DLUA_COMPAT_5_2
# Uncomment the next line if building a 32-bit version of Golly:
# LUA_DEFS = -DLUA_COMPAT_5_2 -DLUA_32BITS

# Change the next line depending on where you installed Python:
PYTHON_INCLUDE = -I"C:\Python27\include"

Save your changes. Switch to the Windows SDK command prompt and build Golly:

Code: Select all

cd your\path\to\golly\gui-wx
nmake -f makefile-win

If there are no errors then Golly.exe (and bgolly.exe) will be created in the parent directory. Double-click on Golly.exe and it should start up!

Any questions? Any problems? (If you do have problems then please copy and paste any error messages here, or upload a screenshot.)

[Andrew]

An important tip I should mention... If you have multiple versions of Golly on your system it's highly advisable to have a separate GollyPrefs file for each version. So create an empty file called GollyPrefs (no extension) in the same folder as Golly.exe, or if you want to use all your settings from an existing version then copy its GollyPrefs file (if it's not with Golly.exe then look in C:\Users\username\AppData\Roaming\Golly\).

[simsim314]

Everything worked OK with wxWidgets, golly compilation was also fine until this linker error:

Code: Select all

        link /LARGEADDRESSAWARE /NOLOGO /OUT:..\Golly.exe   /pdb:"golly.pdb"  /MANIFEST:NO /LIBPATH:C:\wxWidgets\lib\vc_x64_lib /SUBSYSTEM:WINDOWS ObjWin/bigint.obj ObjWin/lifealgo.obj ObjWin/hlifealgo.obj  ObjWin/hlifedraw.obj ObjWin/qlifealgo.obj ObjWin/qlifedraw.obj  ObjWin/jvnalgo.obj ObjWin/ruletreealgo.obj  ObjWin/ruletable_algo.obj ObjWin/ghashbase.obj ObjWin/ruleloaderalgo.obj  ObjWin/ghashdraw.obj ObjWin/readpattern.obj  ObjWin/writepattern.obj ObjWin/liferules.obj ObjWin/util.obj  ObjWin/liferender.obj ObjWin/viewport.obj ObjWin/lifepoll.obj  ObjWin/generationsalgo.obj ObjWin/wxutils.obj ObjWin/wxprefs.obj ObjWin/wxalgos.obj  ObjWin/wxrule.obj ObjWin/wxinfo.obj ObjWin/wxhelp.obj  ObjWin/wxstatus.obj ObjWin/wxview.obj ObjWin/wxrender.obj  ObjWin/wxscript.obj ObjWin/wxlua.obj ObjWin/wxperl.obj ObjWin/wxpython.obj  ObjWin/wxfile.obj ObjWin/wxedit.obj ObjWin/wxcontrol.obj  ObjWin/wxtimeline.obj ObjWin/wxundo.obj ObjWin/wxlayer.obj  ObjWin/wxmain.obj ObjWin/wxselect.obj ObjWin/wxgolly.obj ..\lua\lapi.obj  ..\lua\lauxlib.obj  ..\lua\lbaselib.obj  ..\lua\lbitlib.obj  ..\lua\lcode.obj  ..\lua\lcorolib.obj  ..\lua\lctype.obj  ..\lua\ldblib.obj  ..\lua\ldebug.obj  ..\lua\ldo.obj  ..\lua\ldump.obj  ..\lua\lfunc.obj  ..\lua\lgc.obj  ..\lua\linit.obj  ..\lua\liolib.obj  ..\lua\llex.obj  ..\lua\lmathlib.obj  ..\lua\lmem.obj  ..\lua\loadlib.obj  ..\lua\lobject.obj  ..\lua\lopcodes.obj  ..\lua\loslib.obj  ..\lua\lparser.obj  ..\lua\lstate.obj  ..\lua\lstring.obj  ..\lua\lstrlib.obj  ..\lua\ltable.obj  ..\lua\ltablib.obj  ..\lua\ltm.obj  ..\lua\lundump.obj  ..\lua\lutf8lib.obj  ..\lua\lvm.obj  ..\lua\lzio.obj golly.res  wxmsw30u_html.lib wxmsw30u_adv.lib wxmsw30u_core.lib wxbase30u.lib wxbase30u_net.lib   wxtiff.lib wxjpeg.lib wxpng.lib wxzlib.lib  wxregexu.lib wxexpat.lib  wxmsw30u_gl.lib   kernel32.lib user32.lib gdi32.lib comdlg32.lib  winspool.lib winmm.lib shell32.lib comctl32.lib ole32.lib oleaut32.lib uuid.lib  rpcrt4.lib advapi32.lib wsock32.lib wininet.lib opengl32.lib
LIBCMT.lib(sprintf.obj) : error LNK2005: _sprintf already defined in wxjpeg.lib(wxjpeg_jerror.obj)
LIBCMT.lib(vsprintf.obj) : error LNK2005: __vsprintf_l already defined in wxjpeg.lib(wxjpeg_jerror.obj)
wxjpeg.lib(wxjpeg_jerror.obj) : error LNK2019: unresolved external symbol ___acrt_iob_func referenced in function _output_message
wxpng.lib(wxpng_pngerror.obj) : error LNK2001: unresolved external symbol ___acrt_iob_func
wxjpeg.lib(wxjpeg_jerror.obj) : error LNK2019: unresolved external symbol ___stdio_common_vfprintf referenced in function __vfprintf_l
wxpng.lib(wxpng_pngerror.obj) : error LNK2001: unresolved external symbol ___stdio_common_vfprintf
wxjpeg.lib(wxjpeg_jerror.obj) : error LNK2019: unresolved external symbol ___stdio_common_vsprintf referenced in function __vsnprintf_l
wxzlib.lib(wxzlib_gzlib.obj) : error LNK2001: unresolved external symbol ___stdio_common_vsprintf
wxzlib.lib(wxzlib_gzwrite.obj) : error LNK2001: unresolved external symbol ___stdio_common_vsprintf
wxjpeg.lib(wxjpeg_jmemmgr.obj) : error LNK2019: unresolved external symbol ___stdio_common_vsscanf referenced in function __vsscanf_l
..\Golly.exe : fatal error LNK1120: 4 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.EXE"' : return code '0x460'
Stop.

EDIT I've also compiled on another machine with Windows7 and VS2012 command prompt.

This compilation did worked but generated golly didn't work. When double clicking golly I get this error message:

Code: Select all

---------------------------
Golly.exe - Application Error
---------------------------
The application was unable to start correctly (0xc000007b). Click OK to close the application. 
---------------------------
OK   
---------------------------

@Andrew in windows the compilation is usually done in Visual Studio environment, and the developers are only required add stuff to PATH from time to time. See for example how wxWidgets released solutions for each Visual Studio version in C:\wxWidgets\build\msw directory.

The first thing I think to do if I manage to compile from nmake - is to make golly compile from Visual Studio. VS2013 (community) is now can be freely download.

EDIT The generated bgolly from Windows7 actually worked fine.

[Andrew]

Everything worked OK with wxWidgets, golly compilation was also fine until this linker error

A couple of things you could try. Edit makefile-win and add /NODEFAULTLIB:LIBCMT to the link command options. That might fix the LNK2005 errors. Also try adding legacy_stdio_definitions.lib at the end of the link libraries and see if that fixes the other link errors.

I've also compiled on another machine with Windows7 and VS2012 command prompt.
This compilation did worked but generated golly didn't work. ...

Ouch. You mean the Golly code compiled and linked ok without *any* warnings or error messages, but the resulting Golly.exe doesn't run?! That's a worry. I'd assumed the MS Windows SDK was some sort of compatible subset of Visual Studio, but it sounds like they are quite different.

The first thing I think to do if I manage to compile from nmake - is to make golly compile from Visual Studio.

That would be great if you can manage that. I know nothing about Visual Studio. Even if it's a free download I'm very reluctant to install it on my Win 7 system -- it might stuff up my currently working build environment.

[Andrew]

@simsim314: Another test worth doing would be to see if you can build and run any of the small sample apps supplied with wxWidgets. For example, to build the minimal app:

Code: Select all

cd c:\wxwidgets\samples\minimal
nmake -f makefile.vc

That should create minimal.exe in the vc_mswu_x64 subdirectory. Does it run?

Other samples worth trying are:

Code: Select all

cd c:\wxwidgets\samples\opengl
nmake -f makefile.vc
cd c:\wxwidgets\samples\image
nmake -f makefile.vc

In all cases the .exe files are created in a vc_mswu_x64 subdirectory.

EDIT: It should be easier to get those working with Visual Studio before tackling Golly.

[simsim314]

Another test worth doing would be to see if you can build and run any of the small sample apps supplied with wxWidgets.

I'm now using the machine that compiles golly but can't run its GUI version (windows7). For this machine trying to compile c:\wxwidgets\samples\minimal causes linker error:

Code: Select all

        link /NOLOGO /OUT:vc_mswu_x64\minimal.exe   /pdb:"vc_mswu_x64\minimal.pd
b"   /MACHINE:X64 /LIBPATH:.\..\..\lib\vc_x64_lib /SUBSYSTEM:WINDOWS   @C:\Users
\Owner\AppData\Local\Temp\nmD028.tmp
vc_mswu_x64\minimal_minimal.obj : fatal error LNK1112: module machine type 'X86'
 conflicts with target machine type 'x64'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
\VC\BIN\link.EXE"' : return code '0x458'
Stop.

The same linker error is in other examples as well.

My guess is something in the nmake somewhere is written to compile it in x86 by default, while my compile for golly prepared the wxWidgets to x64. But I'm really not sure.

Ouch. You mean the Golly code compiled and linked ok without *any* warnings or error messages, but the resulting Golly.exe doesn't run?! That's a worry.

Warnings are a tricky thing. I usually assume warning were seen by the developers, and approved. There was no errors indeed - golly.exe and bgolly.exe were created fine. More that that - bgolly.exe was working.

I'd assumed the MS Windows SDK was some sort of compatible subset of Visual Studio, but it sounds like they are quite different.

I can just say that VS2013 and VS2015 command prompts are also quite different. VS2013 is more stable, and got to linker errors while VS2015 failed in much earlier stage. VS2012 is the one that working best, but it can't be installed in Windows10 (Microsoft - go figure).

I think this is why people don't usually use nmake. Once you configure VS solution, it's plug and play. If I open solutions that come with wxWidget and compile them from VS, everything is working pretty well.

----

I'll try to fix the LNK2005 later on, when I get access to windows10 station.

EDIT Your suggestion adding /NODEFAULTLIB:LIBCMT raised some thousand link error of this sort (this is very long list):

Code: Select all

ghashbase.obj : error LNK2001: unresolved external symbol __CxxThrowException@8
ruleloaderalgo.obj : error LNK2001: unresolved external symbol __CxxThrowException@8
ghashdraw.obj : error LNK2001: unresolved external symbol __CxxThrowException@8
qlifealgo.obj : error LNK2001: unresolved external symbol __CxxThrowException@8
qlifedraw.obj : error LNK2001: unresolved external symbol __CxxThrowException@8
jvnalgo.obj : error LNK2001: unresolved external symbol __CxxThrowException@8
ruletreealgo.obj : error LNK2001: unresolved external symbol __CxxThrowException@8
bigint.obj : error LNK2001: unresolved external symbol __CxxThrowException@8
lifealgo.obj : error LNK2001: unresolved external symbol __CxxThrowException@8
hlifealgo.obj : error LNK2001: unresolved external symbol __CxxThrowException@8
hlifedraw.obj : error LNK2001: unresolved external symbol __CxxThrowException@8

[Andrew]

I'm now using the machine that compiles golly but can't run its GUI version (windows7). For this machine trying to compile c:\wxwidgets\samples\minimal causes linker error:

Code: Select all

        link /NOLOGO /OUT:vc_mswu_x64\minimal.exe   /pdb:"vc_mswu_x64\minimal.pd
b"   /MACHINE:X64 /LIBPATH:.\..\..\lib\vc_x64_lib /SUBSYSTEM:WINDOWS   @C:\Users
\Owner\AppData\Local\Temp\nmD028.tmp
vc_mswu_x64\minimal_minimal.obj : fatal error LNK1112: module machine type 'X86'
 conflicts with target machine type 'x64'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0
\VC\BIN\link.EXE"' : return code '0x458'
Stop.

...
My guess is something in the nmake somewhere is written to compile it in x86 by default, while my compile for golly prepared the wxWidgets to x64. But I'm really not sure.

It looks to me like cl is creating 32-bit .obj files (ie. X86). I think you're quite close to getting it working but somehow you need to set the right PATH or other VS environment setting so that cl.exe generates x64 code.

I found a stackoverflow page that might have an answer:
http://stackoverflow.com/questions/2548 ... mmand-line

EDIT: Note that you'll need to rebuild the wxWidgets libs from scratch.

[Andrew]

Instead of doing a 64-bit build of Golly using VS, maybe try a 32-bit build given that it seems to be the VS default?

If you want to try that, I recommend starting from scratch. Trash your existing wxWidgets folder, unpack the wxwidgets .zip file to create a fresh folder, edit wxWidgets\build\msw\config.vc with the same settings I gave above but this time comment out the TARGET_CPU line so that when you run nmake the wx libs will be 32-bit.

Then try building the minimal sample. Does it build and run? If so then at least you should be able to build a 32-bit Golly.

[Andrew]

@simsim314: Another alternative... Forget trying to use Visual Studio. I've done some reading and it sounds like there isn't any problem having both the Windows SDK and Visual Studio installed on the same system. So maybe try downloading and installing the Windows SDK (and .NET stuff if on Win 7) using the links I gave in step 1.

Once installed, use the Start menu to open a Windows SDK command prompt window, then type this command:

Code: Select all

setenv /release

That sets up the environment for a release build. Then proceed from step 2 (starting with a freshly unpacked wxWidgets directory). Probably best to try it on your Win 7 system first because we know that should be possible.

[simsim314]

@Andrew - I've successfully built golly for 32 bit (on Windows10 station).

Few details I should mention:

- I've set TARGET_CPU = X86 in config.vc of wxWidgets.
- In golly local-win.mk, used python 32 bit.
- VS2013 x86 Native Tools Command Prompt.

Not sure all of this is needed - but this definitely worked.

----

I think I'm happy with 32-bit build for now, as I can view golly source and modify it. Thanks a lot!

[Andrew]

@Andrew - I've successfully built golly for 32 bit (on Windows10 station).

Excellent! If you'd like to make changes to the code then feel free to ask any questions, either here or maybe create a new "Golly development" thread.

[rowett]

Here's how I built 64bit Golly on Windows 10 64bit:

1. Download Visual Studio 2015 Community Edition (the free version) from here.
2. Run the installer and make sure Visual C++ is selected in Programming Languages before installing.
3. Once installed run Start->All Apps->Visual Studio 2015->VS 2015 x64 Native Tools Command Prompt and use it for the following steps.
4. Download wxWidgets. If you use the recommended 3.0.2 version you'll have to make manual changes to 3 files. I used the later 3.1.0 release and it builds and works unmodified. Use Andrew's Step 2 above to build.
5. Use Andrew's Step 3 above to download and build 64-bit Python.
6. Use Andrew's Step 4 above to download git and build Golly. In the local-win.mk file you'll need to make WX_RELEASE=31 if you're using wxWidgets 3.1.0.

You should have a working 64bit Golly on Windows 10 64bit.
Good luck!