Building ASCEND for 64-bit Windows

We now have a working version of ASCEND on 64-bit Windows. There's not yet a fully-functional installer, so you will still need to build your own copy from source.

Steps to build ASCEND for 64-bit Windows

We need a complete set of 64-bit build tools, plus 64-bit Python before we can get started:

• install MSYS bundle to c:\msys as instructed here (I chose 'MSYS-20111123.zip')
• install MinGW-64 bundle to c:\mingw64 as instructed (we used mingw-w64-bin_i686-mingw_20111220.zip
• From the MSYS prompt, edit /etc/fstab so that 'c:/MinGW64' is mapped to '/mingw'
• install 64-bit Python 2.7.2
• download and install the SlikSvn 64-bit client.
• append /c/Python27 and /c/Python27/Scripts and SlikSvn to the PATH in MSYS. Also, set an environment variable HOST_PREFIX for the MinGW-w64 compiler (to be used by our SCons script). A good way is by creating the file ~/.profile

export PATH="$PATH:/c/Python27:/c/Python27/Scripts:/c/Program Files/SlikSvn/bin"
export HOST_PREFIX=x86_64-w64-mingw32

• download and extract source tarball for SCons 2.1.0. Build via python setup.py bdist_wininst then install resulting .exe in dist subfolder.
• install 'findutils' by unpacking findutils-4.4.2-2-msys-1.0.13-bin.tar.lzma and unpacking into c:\msys

If the build enviromnent is set up, should then be able to follow the standard instructions to get a copy of the ASCEND code from 'trunk' in our repository then build it with:

• now run 'scons -j4'

Things to check:

• if you already have MinGW on your system the above instructions will need tweaking. We have only tried this on a system without Python or MinGW already installed.
• be sure you have the 64-bit Python package.
• the above will build just 'libascend'. For the CUnit test suite, other solvers, and the GUI, please read on.

We still want to check/look into:

• can we set up a MinGW/MinGW-w64 combined build environment and build both 32- and 64-bit versions on that same machine? Can Python 32-bit and 64-bit coexist? Can we install 32- and 64-bit versions of all the Python modules, and GTK as well?
• rather than using the big bundle MSYS that is provided by the MinGW-w64 project, we should try to use 'standard' MinGW-get-inst for the MSYS portion, and load MinGW-w64 on top of that. Makes obtaining minor utilities like 'find' and 'autoconf' much easier.
• our build tools can be 32-bit, even if the build target is 64-bit.

Test suite

• The CUnit test suites seem to be basically working. We have made changes to CUnit and currently require that you access the svn branch 'mingw64' version of CUnit for ASCEND testing. A new CUnit release is planned.
• Failing test cases:
  • compiler_autodiff (issue with a non-null pointer in line 198)
  • compiler_bintok (program hangs! possibly just a configuration issue? looks like the parser is waiting for input from stdin)
  • compiler_blackbox (lacking error code in return from parse. not Win64 specific)

Check the current build status on our buildbot.

Python bindings

Before MinGW-w64 can link to Python27.dll, you need to download, build, and install a utility called 'gendef' which builds library *.def files that MinGW-w64 can use. The python27.lib file distributed with Python doesn't work with MinGW-w64 (or maybe even for MinGW32?). To build gendef, we used revision r4724 from here (click 'download GNU tarball').

• ./configure --host=x86_64-w64-mingw32 --prefix=/mingw
• make -j4
• make install

Next, run gendef as follows. Using Windows Explorer, copy the file c:\Windows\System32\Python27.dll into c:\Python27\Libs. Then, in MSYS,

• cd /c/Python27/Libs
• gendef Python27.dll
• mv Python27.lib OLD-Python27.lib (just in case?)

Firstly, as per python bug 4709, in c:\Python26\include\pyconfig.h, you need to move the following lines,

#ifdef _WIN64
#define MS_WIN64
#endif

further up the file, to just before the #ifdef _MSC_VER in line 107.

Earlier, we thought that you also needed to patch the Python include file 'modsupport.h'. We don't think that's necessary now, if the above patch is made.

Install SWIGWIN 1.3.40 to c:\MinGW\swigwin-1.3.40 and add it to your MSYS PATH. Note that (bug 494) there is currently a bug in SWIG 2.x that prevents us from using it. It looks like that SWIG bug is fixed in their code, but we have to wait for the SWIG 2.0.5 release.

You can now build the ASCEND Python module, ascpy. It seems to work, but as of writing, there is a crash in the GUI when instantiating a model. It might be that there are still some errors in relation with 64-bit data types, possibly in the ascxx code. With the above, ./test.py TestSolver.testsunpos6 loads and solves a model correctly! Python bindings at least partly operational! Also, pygtk/ascdev models/test/ipopt/test6.a4c seems to work too, if the runtime dependencies listed below are first installed.

Notes about Python with MinGW-w64

There seem to be warnings on the net about MinGW and MinGW-w64 used with SWIG. It has always worked fine for us on Win32, but maybe there are new issues arising. To test this, here is a simple 'hello world' example SWIG module. It works on Ubuntu 11.10 32-bit, and builds fine on Win7 64-bit, but fails with a segfault when exiting.

swigtest.tar.gz (900 byte tarball)

MinGW-w64 can build (without SWIG) against Python 2.7 for at least trivial bindings... we can prove it. A simple example that takes a string, prints it, and calculates its length, seems to work fine:

pytest.tar.gz (1.1k tarball)

Both of the above tests work fine if the patch from python bug 4709 is applied to your installed Python pyconfig.h header file.

Other pages on MinGW with Python:

• http://sebsauvage.net/python/mingw.html (32-bit version)
• http://boodebr.org/main/python/build-windows-extensions

Cunit

• use SVN code from the branch 'mingw64':
  • cd
  • svn co https://cunit.svn.sourceforge.net/svnroot/cunit/branches/mingw64 cunit
  • cd cunit
• ./configure --prefix=/mingw --host=x86_64-w64-mingw32 --build=mingw32
• make install

SUNDIALS

SUNDIALS is used by the IDA solver in ASCEND.

• ./configure --host=x86_64-w64-mingw32 --prefix=/mingw
• make -j4
• make install

IPOPT

• download and extract the 'findutils' lzma tarball from here; put the extract 'find.exe' and 'xargs.exe' into c:/msys/bin.
• download the source tarball for IPOPT 3.10.1
• cd ThirdParty/Blas && ./get.Blas (note that on my system I had to edit the URL in the get.Blas script to use "http:" instead of "ftp:")
• cd ThirdParty/Metis && ./get.Metis
• cd ThirdParty/Mumps && ./get.Mumps
• cd ThirdParty/Lapack && ./get.Lapack (again I needed to edit the script to switch 'ftp' to 'http'.
• ./configure --host=x86_64-w64-mingw32 --prefix=/mingw
• make -j4
• make install

If the install works OK you should have some /mingw/libcoin* and /mingw/libipopt.a files.

This will build you a static IPOPT solver. There isn't a way to build a DLL of IPOPT with MinGW yet, apparently.

To get scons to detect this build of IPOPT, use

scons --config=force -j4 IPOPT_LIBPATH=/mingw/lib IPOPT_PREFIX=/mingw IPOPT_LIBS=ipopt,coinmumps,coinmetis,coinlapack,coinblas,gfortran,stdc++

The above seems to work fine, except that it results in a dynamic link to libgfortran-3.dll that must be satisfied at runtime in order for IPOPT to work. Possibly a solution will be

F77FLAGS="-static" ./configure --host=x86_64-w64-mingw32 --prefix=/mingw

Wait and see if that works...

GDB

• Download the GDB package from the MinGW-64 site here (we chose x86_64-w64-mingw32-gdb-7.1.90.20100730.zip)
• Building GDB from source tarball version 7.3.1 worked OK but the resulting GDB didn't recognise/load symbols from the running executable. So download the MinGW-64 pre-compiled version instead.

Runtime requirements

To actually run the GUI resulting from the above build, you still need to install GTK+, PyGTK, PyCairo, PyGObject. Get the amd64 py2.7 packages from this page:

• http://ftp.gnome.org/pub/GNOME/binaries/win64/gtk+/2.22/
  • get the GTK+ 2.22 runtime 'bundle'
  • extract to c:\GTK
  • make sure you don't have any other GTK installations on your path

• http://www.lfd.uci.edu/~gohlke/pythonlibs
  • py2cairo-1.10.0.win-amd64-py2.7.‌exe
  • pygobject-2.28.6.win-amd64-py2.7.‌exe
  • pygtk-2.22.0.win-amd64-py2.7.‌exe

To test the above:

• c:\GTK\bin must be in your PATH when attempting to run anything that uses GTK.
• gtk-demo.exe should work and pop up a window with some GUI demos
• start up Python and try

Invalid language.

You need to specify a language like this: <source lang="html">...</source>

Supported languages for syntax highlighting:

a4c, abap, abc, abnf, actionscript, ada, agda, alan, algol, ampl, amtrix, applescript, arc, arm, as400cl, ascend, asciidoc, asp, aspect, assembler, ats, autohotkey, autoit, avenue, awk, ballerina, bat, bbcode, bcpl, bibtex, biferno, bison, blitzbasic, bms, bnf, boo, c, carbon, ceylon, charmm, chill, chpl, clean, clearbasic, clipper, clojure, clp, cmake, cobol, coffeescript, coldfusion, conf, cpp2, critic, crk, crystal, cs_block_regex, csharp, css, d, dart, delphi, diff, dockerfile, dts, dylan, ebnf, ebnf2, eiffel, elixir, elm, email, erb, erlang, euphoria, exapunks, excel, express, factor, fame, fasm, felix, fish, fortran77, fortran90, frink, fsharp, fstab, fx, gambas, gdb, gdscript, go, graphviz, haml, hare, haskell, haxe, hcl, html, httpd, hugo, icon, idl, idlang, inc_luatex, informix, ini, innosetup, interlis, io, jam, jasmin, java, javascript, js_regex, json, jsp, jsx, julia, kotlin, ldif, less, lhs, lilypond, limbo, lindenscript, lisp, logtalk, lotos, lotus, lua, luban, makefile, maple, markdown, matlab, maya, mercury, meson, miranda, mod2, mod3, modelica, moon, ms, msl, mssql, mxml, n3, nasal, nbc, nemerle, netrexx, nginx, nice, nim, nix, nsis, nxc, oberon, objc, ocaml, octave, oorexx, org, os, oz, paradox, pas, pdf, perl, php, pike, pl1, plperl, plpython, pltcl, po, polygen, pony, pov, powershell, pro, progress, ps, psl, pure, purebasic, purescript, pyrex, python, q, qmake, qml, qu, r, rebol, rego, rexx, rnc, rpg, rpl, rst, ruby, rust, s, sam, sas, scad, scala, scilab, scss, shellscript, slim, small, smalltalk, sml, snmp, snobol, solidity, spec, spn, sql, squirrel, styl, svg, swift, sybase, tcl, tcsh, terraform, tex, toml, tsql, tsx, ttcn3, txt, typescript, upc, vala, vb, verilog, vhd, vimscript, vue, wat, whiley, wren, xml, xpp, yaiff, yaml, yaml_ansible, yang, zig, znn

Some helpful diagnostics for finding out why 'import gtk' gives errors in some cases: (in my case, I needed to add c:/GTK/bin to the START of my PATH because of a conflicting ZLIB1.DLL earlier in my PATH.

• http://gramps-project.org/wiki/index.php?title=ImportError:_DLL_load_failed

Some optional components that will allow the ASCEND GUI to do more:

• http://www.lfd.uci.edu/~gohlke/pythonlibs/
  • IPython
  • NumPy
  • Matplotlib

Creating the installer

If you have NSIS installed on your system then you will be able to build working installer for ASCEND. It's a 32-bit installer that installs a 64-bit ASCEND library/executable/etc. The installer is not yet fully-functional because it checks for prerequisites but doesn't yet know how to install the missing packages if they're not there.

Some issues to address/check:

• make sure no WoW3264Node confusions arise when trying to install 64-bit ASCEND on 64-bit Windows.
• it should still be possible to install 32-bit ASCEND on 64-bit Windows.
• ensure package works without gfortran, libstdc++, libgcc being present on the system
• how to make sure that installed versions of GTK/Python etc are 64 bit and not 32-bit.
• are there any issues with MSVCR90.DLL not being present? PyGTK seems to depend on it.
• what happens when you try to install on Windows 32? does it fail gracefully?
• consider including all required dependencies in the package: total size would be +~45MB (minus compression savings, minus optimisations from removing unneeded bits of GTK+?)