Building ASCEND for 64-bit Windows

Jump to: navigation, search

We now have a working version of ASCEND on 64-bit Windows. Before you can use these instructions, you need to carefully follow the rather long list of instructions for setting up a MinGW-w64 build environment. If you're interested in building ASCEND for other platforms, see building ASCEND.

Compile-time prerequisites

CUnit testing library

Note the directions for building and installing CUnit as per Developer's Manual#CUnit test suites. For MinGW-w64 use the following steps:

cd ~
svn co svn:// cunit
cd cunit
./configure --prefix=/mingw --enable-examples --enable-debug
make install

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.

Currently, failing test cases on MinGW-w64 are:

    • 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)

You may be able to check the current build status on our buildbot.


SUNDIALS is used by the IDA solver in ASCEND. First download and save sundials-2.4.0 from the SUNDIALS download page. Unpack, build and install as follows:

tar zxf /c/Users/yourusername/Downloads/sundial-2.4.0.tar.gz
cd sundials-2.4.0
./configure --build=x86_64-w64-mingw32 --prefix=/mingw F77=gfortran
make install

SUNDIALS at v2.4.0 doesn't support DESTDIR=~/temp-install in the make install step, which is annoying becuase it's not quite as easy to 'catch' the installed files and distribute a binary.

Note, for 32-bit, use ./configure --prefix=/mingw F77=gfortran above. We need to test again whether the --build=x86_64-w64-mingw32 part is needed for 64-bit builds, or not.


IPOPT is a free open-source optimisation solver which can be accessed from ASCEND.

cd ~
tar zxf Ipopt-3.11.3.tgz
cd Ipopt-3.11.3
  • Download the third-party dependencies
cd ThirdParty/Blas && ./get.Blas
cd ../Metis && ./get.Metis
cd ../Mumps && ./get.Mumps
cd ../Lapack && ./get.Lapack
  • Configure and build IPOPT (configuration takes a several minutes, building takes ~15 min or so):
cd ~/Ipopt-3.11.3
./configure --enable-static=yes --enable-shared=no --prefix=/mingw ADD_FFLAGS="-fopenmp -static-libgcc" --disable-pthread-mumps
make install
make test

Note: above ./configure command is a special workaround for 64-bit Windows. Thanks for Stefan Vigerske and Tony Kelman for their help with these instructions (and for this page), and for the suggested changes to our MinGW-w64 set-up guidelines. See also IPOPT bug 215. It is probable that on 32-bit, a simpler command without the 'ADD_FFLAGS' will work OK, but it may change the resulting DLL dependencies of the final DLL/executables.

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 (although the static libary for IPOPT can be incorporated into a DLL as we have done for our IPOPT external solver in ASCEND).

Currently the resulting IPOPT depends on libgfortran and libstdc++. If you build the resulting static libraries into a DLL or an EXE, that DLL/EXE will have shared library dependencies on the ligfortran and libstdc++ DLLs that come with MinGW/MinGW-w64. We would rather like to have the code from of those external DLLs statically linked, but don't yet know how that's possible.

Building ASCEND

If your Windows build environment is set up correctly, and you have a current copy of the source code (either from our subversion repository or a source-code tarball), you should be able to simply run:

scons -j4

If your environment is set up correctly, your build should complete correctly on both 64-bit and 32-bit build environments.

To run test suites, try

scons test ascend solvers models

This script should run all the test cases currently expected to pass. You can also try

scons test ascend solvers models MALLOC_DEBUG=1

to test those functions which require malloc debugging to also be tested. This latter set of tests removes some other ones because of known memory leakage.

Runtime prerequisites

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:

To test the above:

  • You should be able to start IPython (pylab mode) from the Start menu, without any errors output
  • c:\Program Files\GTK+-2.22\bin\gtk-demo.exe should run from the windows command prompt, and pop up a window with some GUI demos
  • After setting your PATH to include c:\Program Files\GTK+-2.22\bin (and possibly log out and log in again) you should be able to start Python and try:

import gtk
w = gtk.Window()

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.

Building the ASCEND 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.

Before you can build the installer, you need to download the NSIS Inetc plugin, and extract the inetc.dll file into your c:\Program Files (x86)\NSIS plugins folder.

Some issues to address/check:

  • make sure no WoW3264Node confusions arise when trying to install 64-bit ASCEND on 64-bit Windows.
  • possible issue with IPOPT with 32-bit installer used on 64-bit Windows. Also check IPOPT with 64-bit version.
  • 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+?)