svigerske
commented
4 years ago Yes, libtool copies the MKL into other libs when doing static builds. I think that also happened with BuildTools 0.8 sometimes.
libtool tries to explain why it's doing this with copying selected object files to avoid basename conflicts....
So there is some check in libtool, which I'm not really understanding at the moment, but that might explain why it doesn't always do that.
The way how the MKL libs are named and presented in the linker flags may prevent libtool from adding them to the dependency_libs in the .la file.
I'm not sure that there is a good way to link the unittest of CoinUtils with the COINUTILSLIB_LFLAGS. So you suggest to do
unitTest_LDADD = -L../src -lCoinUtils $(COINUTILSLIB_LFLAGS)But the CoinUtils library may sit in ../src/.libs, so that libtool will either not find it, or still picks up ../src/libCoinUtils.la. And since $(COINUTILSLIB_LFLAGS) has been recorded in the dependency_libs of libCoinUtils.la (except for MKL, it seems), dependencies would be duplicated.
Maybe one could extend the Lapack check to actually figure out the path to the MKL libs and add an appropriate -L flag or specify the libraries with full paths, so that libtool will find them for the Clp build.
tkralphs
The static build is failing in master with the
clcompiler when theifortcompiler is also configured. This is because of a tangle of things and I don't know how the solution yet. Here are the commands to replicate. First,The eventual result of this is
So it is trying to include the mkl libraries into the Clp library and cannot find them. Tracing the cause, it is because CoinUtils finds the mkl libraries during its configuration and adds them to the
.pcfile as follows.This happens only because
iforthas also been set up and so the path to the mkl libraries is added to the environment variableLIB. Hence, the libraries are included in the link line forpkg-config --libs coinutilsand we end up withMeanwhile, in the
src/Makefile.amfor Clp (here), we haveIt appears that the
LIBvariable is not checked to find external libraries when linking a library, only when linking an executable, but this is not actually what's happening. The linker is finding the library, but libtool is itself trying to copy the library and this is the part that is failing (at least as far as I can tell right now).This behavior does not arise with Osi, although it has the same setup and
OSILIB_LFLAGSalso includes the mkl libraries, because it seems Osi doesn't actually use any of the symbols in the library, so it is somehow ignored (or something like that, it's not very clear to me). During the Osi build, we getand the library links just fine. It seems to be finding the library, but not trying to copy it.
There is another aspect to this, which is that the error did not happen when linking executables for the unit tests of CoinUtils and Osi. It's still not exactly clear to me what's going on there, but it is at least in part because we are using the .la files for linking those, e.g.,
and in
libCoinUtils.la, we haveso the mkl libraries are not linked. I suppose they are not needed for the CoinUtils unit test, but the autotools doesn't know this. Perhaps it is assuming that the mkl libraries are being rolled into the CoinUtils library, so those are no longer explicit dependencies. Anyway, this opens up a bunch of questions.
*LIB_LFLAGSvariables for figuring out what libraries to link when creating a library (at least with Visual Studio). We use.lafiles for linking executables, but I guess those cannot be used for linking libraries, since we use_LDADDin one case and_LIBADDin the other case.Anyway, this seems to be a thread that I tugged that's unraveling a lot of stuff. I'm still sorting through it, but thought I would get some folks involved (@svigerske @LouHafer )who know more about how the new build system hangs together before going much further.