mkl_sequential static link?

[TimP]

We would like to use mkl_sequential mkl_lapack in a static link. MKL 10 release notes give a lot of strong advice against static links, the only reason given being the possibility of mistakenly linking in more than one OpenMP library. That reasoning doesn't seem to bear on mkl_sequential, as I would think the point of mkl_sequential is to avoid dependency on OpenMP runtime. It does so as I would expect in a dynamic link, contrary to the advice I have seen so far always to link explicitly against libguide and libpthread even when using mkl_sequential.
I have linked successfully with static lapack and mkl_em64t, without OpenMP runtime, but this seems to require mkl_sequential.so. It seems short of the mark to support just 2 of the 3 libraries with static link. Does the advice against static link mean that it will not be supported?
I can't understand how the advice about avoiding static link can avoid the necessity of taking care about which OpenMP runtime is in use when not using mkl_sequential. For example, with forced linkage against libguide, as is being advised, would that not cause a problem for an application which is compiled with gnu or Microsoft OpenMP?

[TimP]

I got one piece of the puzzle solved with help from the MKL support team. For Windows x64, a compile and link command:
ifort -O3 test_mat.f90 mkl_intel_lp64.lib mkl_lapack.lib mkl_em64t.lib mkl_sequential.lib -link -stack:100000000
(32-bit integers) works fine, as does
ifort -O3 -i8 test_mat.f90 mkl_intel_ilp64.lib mkl_lapack.lib mkl_em64t.lib mkl_sequential_dll.lib -link -stack:100000000
(same case, but with all integers promoted to 64-bit).

It seems a bit strange to me to claim that the lp64/ilp64 stuff is obvious in view of the history of linux x86-64, when the "l" part remains different between Windows and linux.

For 32-bit Windows, this case links with mkl_intel_c.lib mkl_core.lib mkl_sequential.lib

For 32-bit linux, link with
-Wl,--start-group /libmkl_intel.a /libmkl_core.a /libmkl_sequential.a -Wl,--end-group
For 64-bit linux (either kind) use libmkl_intel_lp64.a (32-bit integers) or libmkl_intel_ilp64.a (64-bit integers. In the linux library directories, several of the files named .a are not libraries, simply lists of libraries.
Even though mkl_sequential removes the possibility of MKL generated threads, a dependency on -lpthread may remain. This is mentioned in the docs, which the MKL team has agreed to improve.
The docs are supposed to be available as .html on line; it was quite annoying to find Adobe broken on 64-bit Windows.

It seems that the "layered" linking scheme can't truly be bypassed. Under linux, you can see by running 'file *.a' that the non-layered .a files are actually small scripts, which can be used to hide the new layered scheme for those cases where the scripts apply.