Yes, I also noticed there have been no commits since 2012. The last activity on issues was around 2015. So it's probably not as simple as just using the library as is. The replacement headers appear to be auto-generated, with the auto-generation scripts part of the repository, so the scripts could be re-run if necessary. There is also a mention of possible manual edits, so one would have to be careful.

With all this, I'm a little pessimistic about just using the library as-is, but to me it looks like the approach in general makes sense. But it does not look like something to be done in one afternoon.


On the other hand, the *current* OSI README.md, prominently at the GitHub project's start page, says to use lazylpsolverlibs, and there is an OSI issue where they reiterate that this is the way to go for dynamically linking solvers:

https://github.com/coin-or/Osi/issues/95

So if OSI + lazylpsolverlibs doesn't work, I think it would make sense to include the OSI guys in the discussion.


That OSI issue also has a patch to include functionality of this type directly in OSI, which the OSI guys rejected because they want people to use lazylpsolverlibs instead. That reply is from 2019, so they still seem to maintain that lazylpsolverlibs is the supported approach.

Now here is a funny bit: if I read it correctly, the person that suggested the OSI patch was actually the author of lazylpsolverlibs. Whoever addressed the issue didn't comment on that (and probably didn't notice it) and just told him to use his own library instead. The timeline is complicated, but apparently the original OSI patch was from 2010, he got no reply, developed lazylpsolverlibs instead, and then in 2019 he got a reply that his patch will not be accepted and he should use his own library instead (which he developed in the meantime). If nothing else, I think the patch that comes with the issue gives some idea of what needs to be done for this functionality.

I wanted to try an installation with the lazylpsolvers lib but it looks like this project is not maintained any more. The main page is on the google code archive and frozen since google code shut down in 2016. There is an exported repository on GitHub (https://github.com/chmduquesne/lazylpsolverlibs) but it also does not look active. The last commit is 8 years old and in an issue the author mentions moving to a different country and starting a new job where he might not have access to the commercial solvers anymore. I think this means that the replacement headers would be out of date as well (e.g., https://github.com/chmduquesne/lazylpsolverlibs/blob/master/lazylpsolverlibs/ilcplex/cplex.h). So using this library doesn't seem like a viable option.

> Regarding the new dependency, I was mainly worried about complicating the
> installation instructions. Users that don't want an LP solver currently
> only need a few very basic packages they can get through apt on Ubuntu. With
> lazysolverlibs, we'd have a dependency that would require compiling a library
> from source and setting it up in the system correctly.

The library would only be needed if we include LP support and OSI. I think we're talking about two separate things:

1. Make the LP code support lazylpsolverlibs so that we can have an open-source compile that supports the commercial solver.

2. *Requiring* LP support to compile the planner.

I'm interested in both, but we can certainly have 1 without 2. If we have 1 without 2, lazylpsolverlibs would not be needed to compile the planner, in the same way that Osi is currently not needed to compile the planner.

I installed OSI using apt in a container and looked at what libraries are available. It only had libOsi, not libOsiCpx, libOsiSpx, etc. I don't know how to test this further. Maybe I could try installing OSI with the lazy solvers to see what this would add.

Regarding the new dependency, I was mainly worried about complicating the installation instructions. Users that don't want an LP solver currently only need a few very basic packages they can get through apt on Ubuntu. With lazysolverlibs, we'd have a dependency that would require compiling a library from source and setting it up in the system correctly.

> In issue923, Malte wondered if the OSI version from Ubuntu already comes with
> support for lazylpsolverlibs. From looking at the files it installs though, it
> looks like this is not the case. It only installs the core libOsi without any
> specific solver interfaces.

Is there a way to find this out for sure? Wouldn't it need to include *some* solver interface to be usable at all? But perhaps this is not a good direction anyway; I think we've been quite sensitive to specific OSI and solver versions, and depending on a (hard to control) OS-distributed version would perhaps be too fragile anyway, even though it would be nice not to have to install OSI manually.

From my preliminary investigation, lazylpsolverlibs looks like the easiest way to go, especially because of the "OSI in the middle" problem. Or phrased more positively, it looks like OSI solves all the dynamic linking hassle for us.

The lazylpsolverlibs library would be a new dependency, but it doesn't look too bad. It essentially seems to be a very thin wrapper around the commercial solver libraries.

If we want, we can still make the build as configurable as we like and allow disabling lazycplex in the same way that we can currently disable cplex (by not making it available at build time). But for me it would actually be very attractive to at least have the option of a single "default" build that includes everything and compiles and runs both with and without commercial solvers (but of course can only *use* the commercial solvers if available at runtime).

Regarding weak symbols: I'm not too worried about them being non-standard. Everything about dynamic linking is non-standard, as the whole notion of dynamic linking is heavily OS-dependent and C++ is completely agnostic to the concept. But I don't think weak symbols are an option if we don't control the library source code. And if they were an option, they would work quite similarly to the lazylpsolverlibs solution with similar amounts of work necessary to annotate each function (but perhaps some small efficiency advantages by having one less level of indirection).

In issue923, Malte wondered if the OSI version from Ubuntu already comes with support for lazylpsolverlibs. From looking at the files it installs though, it looks like this is not the case. It only installs the core libOsi without any specific solver interfaces.

Our Docker and Singularity containers for the 20.06 release support SoPlex but not CPLEX. We tested a container that dynamically links against CPLEX (see issue923) but the problem with this is that this container then cannot be used without having CPLEX available at runtime.

To have support for CPLEX in our containers, we thus have to change the way we link against CPLEX. 

* dlopen/dlsym might help but it seems like we would have to load everything defined in the CPLEX headers individually. Also, I'm not sure how this would work with OSI in the middle.

* There is an extension for "weak symbols" that sounds related but it is non-standard and probably not supported in all cases we would need it:
https://stackoverflow.com/questions/8610083/optional-shared-libraries

* OSI can link against a lazy version of CPLEX through "lazylpsolverlibs" (see README on https://github.com/coin-or/Osi). This is meant for this purpose but brings in a new dependency. If I understand it correctly, we would have to change our build system to link against lazycplex instead of linking against cplex, which means that lazylpsolverlibs would be a dependency even in the cases where we don't want an LP solver.