Building ASCEND for 64-bit Windows

From ASCEND
Revision as of 08:48, 17 August 2013 by Jpye (talk | contribs) (→SUNDIALS)
Jump to navigation Jump to 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.

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

To get scons to detect this build of IPOPT, use 

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

The above seems to work fine, except that it results (on my system) in dynamic link to libgfortran-3.dll, libquadmath-0.dll, libstdc++-6.dll and libgcc_s_sjlj0.dll all of which must be satisfied at runtime in order for IPOPT to work. We can (and have succeeded to) include those dependencies with the ASCEND installer, but they total an additional 12 MB which we would rather avoid.

To build the ASCEND installer in that case, we use 

scons IPOPT_DLL1=... IPOPT_DLL2=.... IPOPT_DLL3=... IPOPT_DLL4=... installer

where the '...' correspond to the full path to the required DLLs on your particular system. On mine they were in /mingw/lib/i686-w64-mingw32/lib or something like that.

We would like to remove the need for these extra DLLs. One approach would be to link statically to them, but it doesn't seem to work. We tried building IPOPT 3.10.2 with 

 ./configure --enable-shared=no --enable-static=yes FFLAGS="-static-libgfortran" CFLAFGS="-static-libgcc" CXXFLAGS="-static-libstdc++ -static-libgcc" --host=x86_64-w64-mingw32 --prefix=/mingw

but even with all that stuff, the links were still present when it came to creating the ascend_ipopt.dll file.

GDB

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.

This page has been observed to be out-of-date. You can help to update the content, or search for a page containing newer information.

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

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

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

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

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



--- Following material is old and needs to be merged into other sections

This page has been observed to be out-of-date. You can help to update the content, or search for a page containing newer information.
  • 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

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:

Creating the installer

Retrieved from "https://ascend4.org/index.php?title=Building_ASCEND_for_64-bit_Windows&oldid=4373"