Do-a-thon: bringing CBC to the masses

Proposal for: Do-a-thon
by Bryn Pickering and Stefan Pfenninger (ETHZ)

Session Title
Bringing CBC to the masses

Session Description
As will be made apparent in a connected lightning talk, the only viable open-source linear solver is CBC; GLPK is both too slow and inaccurate.

Installing CBC on OSX or Linux is straightforward, there are built packages for both on conda forge. However, many modellers still use Windows, and have to go through a relatively confusing process to get a CBC executable on their device.

We think CBC should be as easily accessible to Windows users as it is to everyone else (even though we actually only work on MacOS!). In this session, we’ll get down and dirty with the CoinCBC conda-forge recipe, with the aim of getting a Windows executable made available.

The intended outcome is simple: a pull request on the CoinCBC conda-forge feedstock respository containing the necessary code to make CBC easily available for Windows devices.

Would you like to be responsible for this Session?

Do you need any special infrastructure for this Session?
Lots of plug sockets, for all the laptops being hooked up.

Do you have any recommendations who could be part of this Session?
Those with software development experience, particularly with regards to creating conda-forge recipes in which an executable is compiled from c++ code.


I’d find this really useful!

Just to note the outcome of this do-a-thon: it’s a real pain. We weren’t successful, but here are the notes we took:

There is a small amount of documentation [1][2] for building on windows, but they depend on a cmake file being available.

Currently, the windows binaries are built [3] using ‘coinbrew’ [4].

Existing conda-forge c++ compilers include vs20XX [5], so one could theoretically run coinbrew in conda-forge to generate the executable.

Additionally, windows binaries depend on access to, which would need adding to the package manually:

  • libblas
  • liblapack
  • libgfortran-5
  • libgcc_s_seh-1
  • libbz2-1
  • libwinpthread-1
  • libstdc++-6
  • libquadmath-0

We don’t know if the dependency on coinbrew and access to these libraries would be possible through conda-forge. Having discussed the problem after the do-a-thon with Benjamin Fuchs at DLR, it seems like the easiest would be to point the windows build directly to the already built binaries [6]. We could then just unpack these and repackage it within conda-forge. Not sure if this fit with conda-forge ‘best practice’, however. It also raises the issue of how to build each of the compiler-specific binaries on conda-forge (win32-msvc9, x86_64-w64-mingw32, win32-msvc15, i686-w64-mingw32, win32-msvc14), or whether to just compile one for python2.7 conda environments (win32-msvc9) and one for python3 conda environments (win32-msvc14), in accordance with recommendations in [7].

We’d still welcome anyone with more knowledge on this subject (conda-forge recipes to compile c++ code on a Windows VM) to come forward. In the meantime I will look to implement the workaround, and see if the feedstock maintainers accept the method.

[7] section 6.1 @

@brynpickering I guess you want a DLL with python bindings, right? Have you considered building on Linux but cross‑compiling for Windows. I’ve only done that for static linking using the GNU GCC compiler. Not sure how that works with shared objects and/or other compilers? Also GLPK used to be built for Windows and with multiple language bindings using SWIG — I don’t know the details but they will be documented or discussed somewhere, if only on the mailing list archive. Just thoughts. R.