Use of the /Qmxl compiler switch

[David_Vowles]

Dear forum members,

I have a question about where and when the /Qmxl compiler switch must be used to ensure that the MXL subroutine library is linked to an application.

I am developing a static library (MYLIB.lib). A number of the modules in the library contain subroutines that make calls LAPACK or BLAS subroutines (e.g. MYSUBA in FILEA.f90, MYSUBB in FILEB.f90, etc.).

A main program (MYPROG in PROGFILE.f90) then makes calls to subroutines in MYLIB. MYPROG indirectly calls LAPACK and BLAS subroutines via calls in MYLIB.

Do I need to use the /Qmxl compiler switch with every source code file that contains a call to an MXL routine (i.e. FILEA.f90, FILEB.f90, etc); or is it sufficient, say, to compile the main program (PROGFILE.f90) only with the /Qmxl switch?

I find it quite confusing why it is necessary to use /Qmxl during compilation when, ultimately, the objective is to link the MXL library with the code.

Thank you,

David.

[TimP]

Do you refer to /Qmkl ?  It's a linker switch, translated to appropriate parameters passed on by ifort to the linkers when using ifort to drive a link.  I don't know what you mean if you are saying it is necessary to specify /Qmkl in a /c or /S compilation where /Qmkl would be ignored.

If your question is about the advisability of setting /Qmkl when building a static library, I'm not prepared to answer.

[mecej4]

I think of /Qmkl as a "no-fuss" option that makes it convenient to build with MKL when there are no complicated run-time requirements. It does the same thing as specifying /I and /D options to the compiler to use MKL include and modules, and specifying the MKL libraries to the linker. The use of /Qmkl is not necessary, but it is very convenient when it suffices. If you need to use F95 interfaces, /Qmkl is not sufficient.

To see things for your self, choose a short example that uses MKL, say pgm.f or pgm.c, and  (i) compile to .obj with the /c option and then do :ifort pgm.obj (or icl pgm.obj); (ii) compile with the /c /Qmkl options and then do ifort pgm.obj. In the first case the linking will fail, and to fix that you could specify the MKL libraries explicitly (consulting the MKL link advisor if needed).  

[David_Vowles]

Dear Tim P & Mecej4, thank you for your replies.

Before my original post I had, of course, referred to the /Qmkl compiler-documentation at (file:///C:/Program%20Files%20(x86)/Intel/Composer%20XE%202015/Documentation/en_US/compiler_f/index.htm)

Though I do understand that /Qmkl is a convenience compiler option what is unclear to me from the above documentation is, for a multi-file project, whether I must use it with every source file containing a call to an MKL routine; or if it is sufficient to use this switch once with, say, the file containing the main program.

I can do experiments, of course, but would have expected that something as basic as this would be included somewhere in the documentation. So if forum members with experience with MKL could point me to more detailed documentation than that in the above compiler-option documentation then that would be much appreciated.

Many thanks,

David. 

[mecej4]

If you compile several Fortran source files into .OBJ files and then do a separate link step, you may choose to use /Qmkl only for those sources that contain USE statements for modules supplied by Intel with MKL.

If you only use F77 interfaces to MKL routines, you would have no USE statements in your sources and you could get by with specifying /Qmkl only in the link step. If, in addition, you choose to specify the necessary MKL libraries explicitly at link time, you would not use /Qmkl at all. You choose.

[David_Vowles]

Thank you for the clarification Mecej4.

Since I use the F77 interfaces to the BLAS & LAPACK libraries I had not considered the possibility that the compiler would need to know the location of module files for MKL. Thus, it did not seem to make sense to me that /Qmkl would need to be specified at compile time. Now I see the point.

A short explanation of these points in the documentation of the /Qmkl switch and including the possibility that it only needs to be supplied when linking if your code does not use modules from the MKL would be helpful.

 Thanks again,

David.

[Steven_L_Intel1]

If your project uses MKL, then it makes sense to use the /Qmkl option for all the compiles. There are, however, usages of MKL which /Qmkl doesn't cover, in which case using MKL's "link line advisor" can be useful (and adding the MKL include folder to your include list).