topic Re: Static linking required for FFTW wrapper? in Intel® oneAPI Math Kernel Library

Static linking required for FFTW wrapper?

mpbro — Wed, 12 Dec 2007 07:17:24 GMT

I had a lot of trouble getting the libraries right to link MKL for use with the FFTW wrapper. Specifically, the examples link in 7 libraries, fftw3xf_intel, mkl_intel_lp64, mkl_intel_thread, mkl_core, guide, pthread, and m. I found that three of these, mkl_intel_lp64, mkl_intel_thread, mkl_core, HAD to be linked statically to get a build. I'm no expert on compilers/linkers, but I would appreciate understanding what's going on so I can ensure portability/stability if I use MKL.

Thanks.

Re: Static linking required for FFTW wrapper?

TimP — Wed, 12 Dec 2007 13:54:03 GMT

MKL 10 pushes the limits further on what is required of the linker. The need for better documentation and more automatic scripting has been recognized.
In my problematic case, I found, by turning on the verbosity option (e.g. gcc -v ) that the arguments aren't passed correctly to the linker. By examining what the compiler sends on through, I could construct a correct script to invoke ld directly.
In your work-around, did you check that those libraries are linked only statically, by using ldd? I guess you are working with gcc without openmp, as you imply you linked with -lguide -lpthread -lm. A bit of an example would have saved some guessing.

Re: Static linking required for FFTW wrapper?

mpbro — Wed, 12 Dec 2007 15:30:46 GMT

Hi Tim,

Yes, I should have posted some usage examples. Let me do that now. Here are the libraries being used, some various definitions, and the make rule of interest:

MKLLIB = -L/opt/intel/mkl/10.0.1.014/lib/em64t
-lfftw3xf_intel
/opt/intel/mkl/10.0.1.014/lib/em64t/libmkl_intel_lp64.a
-Wl,--start-group
/opt/intel/mkl/10.0.1.014/lib/em64t/libmkl_intel_thread.a
/opt/intel/mkl/10.0.1.014/lib/em64t/libmkl_core.a
-Wl,--end-group
-lguide
-lpthread
-lm

PPCF90 = /home/seispak/Software/moware-1.0/f90ppr
F90 = ifort
F90FLAGS = -O3 -tpp7 -w -i-static -WB -Vaxlib -fpp -vms -DIFORT -CB
MKLINC = -I/opt/intel/mkl/10.0.1.014/include -I/opt/intel/mkl/10.0.1.014/include/fftw

FFT_Test_MKL: ${S}/FFT_Test.f90 ${S}/system_time.f90
${F90} -c ${F90FLAGS} ${S}/system_time.f90
${PPCF90} < ${S}/FFT_Test.f90 > cpp_FFT_Test.f90
${F90} -c -DMKL ${F90FLAGS} cpp_FFT_Test.f90 -o FFT_Test.o
${F90} -DMKL_SINGLE ${F90FLAGS} ${MKLINC} FFT_Test.o system_time.o ${MKLLIB} -o $@

I'm using a pre-processor to resolve some #ifdefs in the main program (sfftw_thread... when running normal FFTW). I'm doing all my compiling and linking with ifort. I guess ifort links with ld?

I can get a working build if and only if the statically linked libraries in $MKLLIB are statically linked.

Let me know if you need more information to understand where I'm coming from. I'm no expert with compilers and barely know enough to be dangerous.

Re: Static linking required for FFTW wrapper?

TimP — Wed, 12 Dec 2007 16:52:31 GMT

Yes, ifort generates an ld script. You have a combination of ifort 7.x and 9.x options which request a static link of libguide, if ifort notices that libguide is needed. That does appear to be inconsistent with an attempt to make a dynamic link of libraries which require libguide. So, I'm guessing that you may have meant to use -static-libcxa rather than -i-static, if that is the option for your compiler version to link the Intel c++ libraries static but link libguide dynamic.
Anyway, with your combination of options from varying times in the past, your specific combination would not have been tested. Most of the obsolete options should have no effect. -CB should be equivalent to a current check bounds option. -lm is always supplied by ifort, so if you needed that option, something else may have gone wrong.
You can add the ifort option -#x to see what actually goes in the ld script. You could compare what you get with the working invocation against the one you want, possibly getting a clue what went wrong. Admittedly, it could require someone expert in the way MKL 10 is intended to link.
My own troublesome cases involve static link, but they work as they should with all libraries permitted to default to dynamic.