unittest build fails, claims it cannot find and link with the CoinUtils library

[bcdandurand]

After cloning the repository and cd into FlopCpp:

$ sudo ./configure > log.txt

Configuration is successful. However, it is relevant for this ticket to note that there does not seem to be a check for the COIN-OR package CoinUtils. From the configure script output in log.txt:

checking for pkg-config... pkg-config
checking pkg-config is at least version 0.16.0... yes
checking for COIN-OR package Osi... yes: devel
checking for COIN-OR package Cbc... yes: devel
checking for COIN-OR package Clp... yes: devel
checking whether this is a VPATH configuration... no
configure: configuring doxygen documentation options

Next, running make:
$ sudo make

Make appears to be successful.

Now testing:
$ sudo make test &> testout.txt

From the testout.txt:

...
creating unitTest
./unitTest
/home/bcdandurand/COIN-OR/FlopCpp/FlopCpp/unittest/.libs/lt-unitTest: error while loading shared libraries: libCoinUtils.so.0: cannot open shared object file: No such file or directory
make[2]: *** [Makefile:547: test] Error 127
make[2]: Leaving directory '/home/bcdandurand/COIN-OR/FlopCpp/FlopCpp/unittest'
make[1]: *** [Makefile:794: test] Error 2
make[1]: Leaving directory '/home/bcdandurand/COIN-OR/FlopCpp/FlopCpp'
make: *** [Makefile:679: test] Error 2

I know I have the needed CoinUtils libraries installed in my /usr/local/lib as with other COIN-OR libraries. As noted earlier, the configure script of the root FlopCpp directory does not seem to check for this library (it checks for other needed COIN-OR libraries as seen above). Also, CoinUtils is listed under FlopCpp/Dependencies.

I am attempting this build in WSL 2 with Ubuntu.

[tkralphs]

Indeed, the configure script in the FlopCpp subdirectory does not check for CoinUtils. This is partly an artifact of the way the build system used to work when we were using subversion, but also perhaps because CoinUtils is not a direct dependency (I assume?) and so we really shouldn't need to check for it if Osi/Cbc/Clp are already installed (since they should have checked for it). There are some changes that should be made to this project now that it's managed under git and it should also be switched to the newer version of our build tools. But I haven't gotten around to doing all of this---it's not a high priority since it's not used much now (as far as I know).

As for a practical fix right now, can you say how are you doing this build? It would seem to be very difficult to avoid having CoinUtils installed and still have the other dependencies. I can't really think of a way this could happen. If you're using [coinbrew}(https://github.com/coin-or/coinbrew), then CoinUtils is listed as a dependency and would be built automatically, even if the configure script is not checking for it. If you built Osi/Clp/Cbc and installed them separately, then CoinUtils would need to be installed when installing those packages. If you're using a package manager, then CoinUtils should be installed that way, too. I can't think of how this could actually happen without uninstalling CoinUtils inadvertently or maybe building CoinUtils in a local build directory and then not installing it, but installing other packages?

In any case, if you use coinbrew, you should have no problems. That is the recommended way to build in WSL2, which is where I also work most of the time.

[bcdandurand]

I used coinbrew to build the entire COIN-OR-OptimizationSuite successfully today. I was ultimately after a successful testing and installing of Smi, which I have as evidenced by being able to use its library functionality in a separate repository of code.

Before installing the COIN-OR-OptimizationSuite, I tried to use coinbrew to install only Smi (with its dependencies). This attempt failed, and I don't have record of the error, but I recall that the failure occurred during the building of CoinUtils due to the apparent non-detection of COIN-OR based dependencies. (These dependences were otherwise clearly detected when installing COIN-OR-OptimizationSuite). I'll try to reproduce the error in a dummy installation attempt and open an issue under Smi.

For my part, this issue may be closed. I'll leave it up to a developer to decide whether to close this issue now.

Thank you.