Hi,
This problem popped up downstream in R (https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17443) when it is linked with MKL on Linux (I don't know about Windows/OSX). R is a an extensible program, one may write dlls/shared libraries in C which is linked into R at runtime. Now, here is a problem. MKL contains wrappers for fftw, some of them do not work, for instance multidimensional r2r transforms, or strided r2r transforms (which can easily be utilized to make multidimensional ones). I make a shared library for R which uses these parts of fftw3:
# gcc -shared -o foo.so foo.c -lfftw3
Everything seems fine. I start R, it is linked with MKL to have a nice optimized, parallel BLAS, say -lmkl_rt, and loads symbols from there. When I from R load (dlopen) my foo.so, the fftw-references in there are resolved to MKL which is already loaded in R, and they do not work. There is no easy way for my foo.so to get hold of the real fftw3-routines. A workaround is a little bit cumbersome, I can either link R with parts of MKL static (like -Bstatic,-lmkl_gf_lp64,-Bdynamic -lmkl_gnu_threads ...), or link my foo.so with a static libfftw3.a, or preload R with LD_PRELOAD=libfftw3.so.
My question is, would it be possible to ship MKL's fftw-wrappers separate from the working parts of MKL so that it would be possible to avoid the poor fftw masquerade?
