Closed Fabian188 closed 3 years ago
Try adding also --with-lapack
. There is a bug that has been fixed in the current branch, but not released yet.
The one where MKL was actually used is the one where MKL is available in the library search path, so configure can find it automatically.
Thanks for your reply!
I tried with a tailing --with-lapack and --with-lapack=yes and got the error
checking for LAPACK... configure: error: Cannot link to user-specified Lapack "-L/opt/intel/mkl/lib/intel64 -Wl,--no-as-needed -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lm".
I guess, the new release is not planned within the next days? :)
You mean LD_LIBRARY_PATH? I could set it to /opt/intel/mkl/lib/intel64 as first entry before configure. [EDIT: I tried to set it (not perfectly sure, if it worked out of cmake) but had no success.
Or is there an as zip downloadable commit I can use instead?
Thanks!
I guess the issue with --with-lapack is, that there is something like a
test -z "$with_lapack_lflags"
but I set according to the instructions
--with-lapack-lflags="-L${MKL_LIB_DIR} -Wl,--no-as-needed -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lm"
Unfortunately I have a very low understanding from how configure works, as I usually use cmake.
The variable seems to be LIBRARY_PATH (I only knew LD_LIBRARY_PATH).
On the ubuntu 20.04 I sourced mklvars.sh and configure worked. Then I unset more and more variables up to I found LIBRARY_PATH and adding it manually in cmake as
CONFIGURE_COMMAND env "LIBRARY_PATH=${MKL_LIB_DIR}" ${IPOPT_SOURCE}/configure --with-lapack-lflags=....
seems to work.
Thanks for your reply!
I tried with a tailing --with-lapack and --with-lapack=yes and got the error
checking for LAPACK... configure: error: Cannot link to user-specified Lapack "-L/opt/intel/mkl/lib/intel64 -Wl,--no-as-needed -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lm".
That one means that something is wrong with these flags. The config.log file should give more details on why the link-check failed.
I guess, the new release is not planned within the next days? :)
You mean LD_LIBRARY_PATH? I could set it to /opt/intel/mkl/lib/intel64 as first entry before configure. [EDIT: I tried to set it (not perfectly sure, if it worked out of cmake) but had no success.
I meant the path where the compiler/linker is looking for libraries.
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html mentions LIBRARY_PATH
.
Or is there an as zip downloadable commit I can use instead?
Current stable branch: https://github.com/coin-or/Ipopt/archive/refs/heads/stable/3.14.zip
@svigerske Thanks a lot! By your hint I found a good workaround and learned something new about LIBRARY_PATH.
From my point of view this issue could be closed?!
This issue shouldn't have been closed, since it's not resolved. I just had the same issue as well. The problem is that the configure script has a bug and passes "-L/opt/intel/mkl/lib/intel64 -Wl,--no-as-needed -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lm"
with the quotes.
Can you be more specific where in configure it passes something with quotes? How do you call configure exactly and where do the wrong quotes appear?
We have an academic FE code and I want to update from a fairly old ipopt version to 3.14.2. We have Intel MKL in our code and I build ipopt via cmake external project. This worked out of the box for newest macOS, current openSUSE tumbelweed and Ubunutu 20.04. However I have issues with some runner of our build-pipeline. Unfortunately I have no direct access to this build systems to do experiments.
From https://coin-or.github.io/Ipopt/INSTALL.html I use
configure --with-lapack-lflags="-L${MKL_LIB_DIR} -Wl,--no-as-needed -lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lm"
And I assert, that ${MKL_LIB_DIR}/libmkl_intel_lp64.a exists.This is working Ubuntu 20.04
This is working macOS
This is a working gitlab runner current openSUSE Leap
This is a failed gitlab runner (centos6)
Another failed gitlab runner (fedora32)
It works also for centos7 with intel compiler and openSUSE tumbleweed.
I have no idea, how it is searched for lapack, strange is, that the results for the given working examples are completely different, whereas I assumend the command line simply tells to use mkl.
[Edit:] I just realized, that only the variants
checking for LAPACK... yes: Intel MKL (-lmkl_intel_lp64 -lmkl_sequential -lmkl_core -lm)
work at runtime and find pardiso_.How to enforce that mkl is used and found?
Do you have any idea? Thanks a lot.