Building ASCEND for 64-bit Windows

There are a number of barriers to building ASCEND on 64-bit Windows:

• 'Standard' MinGW does not build 64-bit executables, so we need to use the MinGW-w64 compiler, which is a bit new.
• We need to switch to a true 64-bit Python in order to run 64-bit ASCEND.
• PyGTK for 64-bit may have some bugs (http://www.daa.com.au/pipermail/pygtk/2009-July/017278.html)
• Windows 64 uses 8-byte pointers (long long) which our code hasn't had to deal with up to now.

This page records our progress on getting up and running.

Steps to date

• install MSYS bundle to c:\msys as instructed here
• install MinGW-64 bundle to c:\mingw64 as instructed (we used mingw-w64-bin_i686-mingw_20111220.zip
• install 64-bit Python 2.7.2
• append /c/Python27 and /c/Python27/Scripts to the PATH in MSYS.
• download and extract source tarball for SCons 1.2.0. Build via python setup.py bdist_wininst then install resulting .exe in dist subfolder.
• create 'scons' file in c:\Python27\Scripts containing

#!/bin/sh
python /c/Python27/Scripts/scons.py $*

• svn checkout ASCEND source code (from trunk)
• scons

Things we need to work on:

• A lot of new compiler warnings due to the very new GCC version 4.7 used by MinGW-64 that will need to be worked through.
• Installing the MinGW-64 toolchain with 'standard' (local) tool filenames (maybe a quick script to rename or symlink them?)
• Detecting 32-bit vs 64-bit Windows?
• Detecting Python linker flags
• Building PyGTK etc for our version of Python
• Packaging it all (will NSIS 32-bit be OK to use?)
• Conversions between 'void *' and 'unsigned long' don't seem to work on Win64. Instead, Windows wants 'void *' to be cast to 'unsigned long long', since those pointers are the same size.
• Something strange happening with MMIO...?
• it's probably going to be better and easier to use the MSYS package from the MinGW project, and then to just overlay the Mingw-w64 files within that environment. Need to check that it works.
• there doesn't seem to be any harm in using a 32-bit compiler executable, even if the target is 64-bit.
• the python lib distributed with Python needs to be tweaked, see http://docs.python.org/install/index.html#gnu-c-cygwin-mingw

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 trunk 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 conifuration issue?)
  • solver_ipopt.formula (crashes, but all other tests are fine)
  • utilities_ascSignal (appears not to be an issue only with Win64)
  • compiler_blackbox (lacking error code in return from parse. not Win64 specific)

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.

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 trunk code
• ./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
• ./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.