MKL linking with MinGW64, is it still impossible?

MKL linking with MinGW64, is it still impossible?

Hi, all.

We can find similar topics on it such as https://software.intel.com/en-us/forums/intel-math-kernel-library/topic/277796

It is from 2012, but how is the situation now in 2018? I am trying to replace FFTW3 with MKL due to licensing reasons. The header has:

#include <mkl_dfti.h>
#include <fftw3_mkl.h>

Which can be redundant because fftw3_mkl.h includes most needed stuff. My compilation process is in a Makefile and the MKL-related parts look like this:

MKL_DIR = "c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl"
MKL_INC = -I$(MKL_DIR)/include -I$(MKL_DIR)/include/fftw
MKL_LIBS = $(MKL_DIR)/lib/intel64_win
MKL_ALL = $(MKL_INC) -L$(MKL_LIBS) -lmkl_core -lmkl_intel_lp64 -lm

CXX = g++
CXXFLAGS = -Wall -pthread -mms-bitfields -m64

app:
    $(CXX) $(CXXFLAGS) -o $(BINDIR)/$(EXEC_WIN) $(HELPER_OBJS) $(APP_OBJ) $(MKL_ALL)

The objects will be generated fine, as you probably know if you use MinGW64. But this target, app, which will do the linking, outputs the following error for this configuration, which I borrowed from the Intel online linking guide:

==== BUNCH OF ERROR TEXT ====

c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(_free.obj):(.text[mkl_free]+0x4): undefined reference to `mkl_serv_free'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(_free.obj):(.text[MKL_free]+0x1): undefined reference to `mkl_serv_free'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(_malloc.obj):(.text[mkl_malloc]+0x6): undefined reference to `mkl_serv_malloc'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(_malloc.obj):(.text[MKL_malloc]+0x1): undefined reference to `mkl_serv_malloc'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(fftwf_plan_dft_r2c.obj):(.text[fftwf_plan_dft_r2c]+0x22c): undefined reference to `__security_check_cookie'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(fftwf_plan_dft_r2c.obj):(.xdata+0x10): undefined reference to `__GSHandlerCheck'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(fftwf_plan_guru64_dft_r2c.obj):(.text[fftwf_plan_guru64_dft_r2c]+0x207): undefined reference to `__security_check_cookie'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(fftwf_plan_guru64_dft_r2c.obj):(.xdata+0x14): undefined reference to `__GSHandlerCheck'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dfticommitdescriptor_lp64.obj):(.text[DftiCommitDescriptor]+0x28): undefined reference to `mkl_dft_dfti_verbose'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dfticreatedescriptor_s_1d_lp64.obj):(.text[DftiCreateDescriptor_s_1d]+0x61): undefined reference to `mkl_dft_dfti_create_sc1d'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dfticreatedescriptor_s_1d_lp64.obj):(.text[DftiCreateDescriptor_s_1d]+0x79): undefined reference to `mkl_dft_dfti_create_sr1d'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dfticreatedescriptor_s_1d_lp64.obj):(.text[DftiCreateDescriptor_s_1d]+0x8a): undefined reference to `mkl_dft_bless_node_omp'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dfticreatedescriptor_s_md_lp64.obj):(.text[DftiCreateDescriptor_s_md]+0x220): undefined reference to `mkl_dft_dfti_create_scmd'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dfticreatedescriptor_s_md_lp64.obj):(.text[DftiCreateDescriptor_s_md]+0x23f): undefined reference to `mkl_dft_dfti_create_srmd'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dfticreatedescriptor_s_md_lp64.obj):(.text[DftiCreateDescriptor_s_md]+0x24e): undefined reference to `mkl_dft_bless_node_omp'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dfticreatedescriptor_s_md_lp64.obj):(.text[DftiCreateDescriptor_s_md]+0x2a2): undefined reference to `__security_check_cookie'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dfticreatedescriptor_s_md_lp64.obj):(.xdata+0xc): undefined reference to `__GSHandlerCheck'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dftisetvalue_lp64.obj):(.text[DftiSetValue]+0x108): undefined reference to `mkl_serv_strnlen_s'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dftisetvalue_lp64.obj):(.text[DftiSetValue]+0x316): undefined reference to `__security_check_cookie'
c:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2018.3.210/windows/mkl/lib/intel64_win/mkl_intel_lp64.lib(dftisetvalue_lp64.obj):(.xdata+0xc): undefined reference to `__GSHandlerCheck'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:75: windows] Error 1

My MingW64 is from a MSYS2 installation, version is 7.3.0. Is it still a no go, this linking is not going to happen?

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Any major change in the status of this would depend on those efforts to increase the versatility of mingw in dealing with more visual studio compatibility issues.  I don't know of success there.

It looks like you are counting on the MKL Windows libraries having the same names as the linux ones.  Unless you have checked this, it would easily explain such problems. Anyway, you would consult the MKL link advisor for Windows and adapt its recommendations to Make and mingw linking syntax.   I doubt -lm is necessary or compatible with Windows (redundant even on linux when linking with C++ rather than C).  -pthread wouldn't do anything for you; if you want to use MKL parallel you must link libiomp5 and not use any OpenMP in gcc/g++/gfortran other than what is implied in MKL.  If you want to use OpenMP in your code, you will need to link MKL sequential (or link OpenMP stubs) so MKL doesn't invoke OpenMP within itself.  Omitting the specification of parallel or sequential library also gives you undefined references.

MKL depends on a bunch of libraries from Visual Studio, not present in a plain mingw installation.  I don't know whether you can bridge the gap with a Windows SDK.

I don't understand how licensing issues could require you to use fftw from MKL rather than some other source.  The point of MKL is to save you a lot of optimization effort.  With Intel compilers, you can simply use the MKL link specification for simple cases and not need to check the link advisor.

Good morning, Tim.

First of all, thanks for your reply. I read your considerations carefully and understand that it is not MKL who doesn't "want" to work with MingW, but the latter not fully compatible with VS stuff that MKL depends on. In this case, it is better if I just go to VS and create a DLL there to call from my main program. I already had to do it with CUDA stuff, which also won't compile with MingW but the DLL from VS works just fine.

I took these compilation flags from the linking advisor, where I selected Linux and copied some flags to the MingW makefile. I had to remove -ldl and -libiomp5 because those don't seem to exist in Windows (make complained). -lm doesn't seem to have any effect either. I was initially including mkl_intel_thread.lib, but it would cause 30+ error lines to show, so I omitted it to see what kind of suggestion you guys would make. Today I will take this to VS2017 and will report back if I manage or still have issues.

The licensing thing is because my main program has a GTKmm interface (LGPL), which allows me to link closed source code to it. Should I have kept FFTW3, which is GPL, it would require everything else to be open. Which I can't do, since some code I'm using don't belong to me.

Thanks a lot for your time and this explanation. I will let you know how it goes.

Good evening, Tim.

Moving to VS2017, as expected, worked. It compiled the code with FFTW wrappers just with a million warnings of things being previously defined, but no major issues. However, straying away from MingW now, please let me ask you a few more things:

- My VS2017 project includes the following MKL libs: mkl_intel_lp64.lib, mkl_intel_thread.lib, mkl_core.lib. In the lib directory there are other files that end with _dll in their name? What are and when should they be used, as I don't seem to find info on it?

- When the project compiles to a static .lib file, it generates the lib with approximately 23MB. However, when compiling my host program pointing to this lib, it complains about undefined references if I try to call any of the functions from my lib. Everything is properly declared as extern "C" and exported/imported.

- When I change the project to compile to a dynamic .dll and use it instead of the static .lib, then the host program compiles without any warning, but it requires the redist .dlls to either be in the path or in the exe directory. In my MKL installation I have both mkl_core.dll and mkl_intel_thread.dll and copied them, but it also asks for libiomp5md.dll. What do I need to install to have it?

- If I want to use MKL's random number generator, can I choose the type of parallel technique it is going to use? There are a number available, libe TBB, Sequential (???), OpenMP...

Thanks a lot for any guidance.

Good morning, all.

I'd like to consider this topic closed as I got enough explanation from Tim which allowed me to advance a bit more on the work.

The other questions I have are no longer pertinent to the original post.

Thanks all.

Leave a Comment

Please sign in to add a comment. Not a member? Join today