Windows binaries

[andreaslundell]

As it seems that there are no recent Ipopt binaries built with Visual Studio available, would it be possible to make the ones compiled by Appveyor available somehow, e.g. on Bintray? Similarly to what is (I guess) done for Cbc?

[tkralphs]

As far as I can see, the only build being done on Appveyor at the moment is with the MinGW compiler, not Visual Studio. To make Visual Studio libraries, we need the ifort Fortran compiler (to build Mumps) and it's not available on Appveyor. We don't really have an automated way of providing Visual Studio binaries for Ipopt at the moment. Stefan or I can manually build a binary periodically and upload it (which is how I guess the existing binaries were built). But that is the only option currently, as far as I know.

[andreaslundell]

Aahh... I missed that Visual Studio was only the name of the image while the architecture was still MinGW... Thanks anyway!

[chrisdembia]

Another option is to use f8/flang instead of Intel Fortran, though this new Fortran compiler is still under development.

[tkralphs]

I've been wondering when there would eventually be an open-source compiler to replace ifort. Good to see this one being developed, although it looks they don't really support Windows yet. Another alternative is to figure out a way to make the libraries produced by MinGW work with Visual Studio, which can be done in principle. There are tools for doing it, but it always seems a bit like black magic and I don't fully understand the issues.

[chrisdembia]

In https://github.com/opensim-org/opensim-moco, we are using a version of Ipopt compiled with Visual Studio, with mumps compiled with a version of flang that was temporarily available through Conda on Windows.

It’s fantastic to see improvements to the distribution and compiling of Ipopt!

[tkralphs]

@chrisdembia Thanks, I took a look, but I couldn't easily see what you're doing. You said "temporarily available." So that means it is no longer? Are you just using a binary that you have no way of re-generating then?

[chrisdembia]

So that means it is no longer?

That's my understanding.

Are you just using a binary that you have no way of re-generating then?

Sadly, yes. I had intended to create a script to reproduce this binary but it was a very lengthy difficult process and may be irrelevant anyway, given that I'm not sure Conda provides this version of Flang on Windows anymore. Part of this process involved modifying the coinor CMake scripts that were on GitHub: https://github.com/chrisdembia/coin/tree/ipopt_external_mumps. IPOPT is an essential dependency of our optimal control software for human movement, so I would love to make our building of IPOPT more robust.

The binary is available here: https://sourceforge.net/projects/myosin/files/ipopt/

Creating this binary was only possible by following the excellent work of @traversaro and others. See robotology-legacy/icub-packaging#7 for a lengthy discussion.

Relatedly, I would be happy to contribute a CMake build system to this repository, if you're interested and able to answer questions that may come up.

cc my colleagues @nickbianco @carmichaelong

[traversaro]

Creating this binary was only possible by following the excellent work of @traversaro and others. See robotology-legacy/icub-packaging#7 for a lengthy discussion.

Fortunately since then there have been some updates that it may be worth mentioning:

• mingw-w64 since version 7.0.0 (https://sourceforge.net/p/mingw-w64/mailman/message/36804945/) supports officially linking against the ucrt, even if I guess that the provided binaries does not have support for ucrt enabled, and you need to manually compile mingw-w64 to have ucrt support.
• CMake's property GNUtoMS is supported on Ninja generator since CMake 3.10 .

More related to the content of this issue, it seems that the ampl/coin repo has some scripts to automatically produce binaries of IPOPT for Windows using Visual Studio + mingw-w64 for the Fortran parts (see https://github.com/ampl/coin/blob/master/azure-pipelines.yml#L75), but I did not checked all the details.

[svigerske]

Aahh... I missed that Visual Studio was only the name of the image while the architecture was still MinGW... Thanks anyway!

Yes, the MinGW build would have dependencies onto MinGW DLLs, and I don't want to redistribute these.
I've now uploaded a Ipopt 3.13.2 build for Win64 at the 3.13.2 release page.
Preferably you have MSVS 2019 and Intel 2020 runtime libraries installed, but I believe I also included all necessary DLLs.