Building ASCEND for 64-bit Windows: Difference between revisions

From ASCEND
Jump to navigation Jump to search
Line 54: Line 54:
  make test
  make test


Thanks for Stefan Vigerske and Tony Kelman for their help with these instructions (and for [http://www.mpclab.net/Trac/wiki/CompilingIpopt#MinGW this page], and for the suggested changes to our [[Setting up a MinGW-w64 build environment|MinGW-w64 set-up guidelines]].
Thanks for Stefan Vigerske and Tony Kelman for their help with these instructions (and for [http://www.mpclab.net/Trac/wiki/CompilingIpopt#MinGW this page]), and for the suggested changes to our [[Setting up a MinGW-w64 build environment|MinGW-w64 set-up guidelines]].


If the install works OK you should have some /mingw/libcoin* and /mingw/libipopt.a files.
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.
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 <tt>solvers/ipopt/ipopt_ascend.dll</tt> has a dependency on <tt>pthreadGC2_64.dll</tt>, which we're not able to avoid (ie include via static linking). But everything else seems to be fine. The problem with this pthread dependency is that pthreadGC2_64.dll is not present in the rubenvb version of MinGW-w64, which means that we can't (I don't think) distribute a binary/compiled copy of IPOPT and expect it to work for all MinGW-w64 users.
Currently, the resulting <tt>solvers/ipopt/ipopt_ascend.dll</tt> has a dependency on <tt>pthreadGC2_64.dll</tt>, which we're not able to avoid (ie include via static linking). But everything else seems to be fine. The problem with this pthread dependency is that pthreadGC2_64.dll is not present in the rubenvb version of MinGW-w64, which means that we can't (I don't think) distribute a binary/compiled copy of IPOPT and expect it to work for all MinGW-w64 users.

Revision as of 05:59, 19 August 2013

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.

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://svn.code.sf.net/p/cunit/code/branches/mingw64 cunit
cd cunit
./configure --prefix=/mingw --enable-examples --enable-debug
make -j4
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

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 -j4
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.

IPOPT

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

wget http://www.coin-or.org/download/source/Ipopt/Ipopt-3.11.3.tgz 
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):
./configure --enable-static=yes --enable-shared=no --host=x86_64-w64-mingw32 --prefix=/mingw ADD_FFLAGS="-fopenmp -static-libgcc"
make -j4
make install
make test

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.

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 solvers/ipopt/ipopt_ascend.dll has a dependency on pthreadGC2_64.dll, which we're not able to avoid (ie include via static linking). But everything else seems to be fine. The problem with this pthread dependency is that pthreadGC2_64.dll is not present in the rubenvb version of MinGW-w64, which means that we can't (I don't think) distribute a binary/compiled copy of IPOPT and expect it to work for all MinGW-w64 users.

GDB

gdb seems to be included the current MinGW-w64 package (see setting up a MinGW-w64 build environment), so the following is probably not required any more

GDB is helpful for debugging the location of crashes, errors, etc. It requires a specially-compiled version of an executable, which with GCC is specified by adding -g at compile-time.

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

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.

Building ASCEND

scons -j4

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+?)