fortranintel-fortran

Linker, libs, exe and dependencies


Let's say I have projects B to Z which all have project A (which produces a .lib) in their Visual Studio solution. So for instance, Solution B would be:

B.sln
|______A.vfproj
|______B.vfproj

Where B produces an exe (B to Z can be a mix of exes and DLLs). Now, let's assume B is the only project to use a subroutine in A. That subroutine relies on some Intel MKL function.

Now, should project A tell the compiler to (statically) link to certain libraries in MKL through the Qmkl compiler flag, or is it better to left it to "No" and have project B set its flag to either "parallel" or "sequential" instead? What will be the impact, if any, on projects C to Z if Qmkl is set in A? Will A increase in size, and C to Z as well in turn?


Solution

  • My usual advice for Intel Fortran static library projects is to set the project compiler property Libraries > Disable default library search rules to "Yes". If this option is set to "No", the default, then the compiler inserts linker directives into each object file that name each run-time library the linker should look for. You can see a list of these by executing the command dumpbin -directives a.obj.

    If you add one of the /Qmkl options, the appropriate MKL (and OpenMP) libraries are included in these directives. The problem comes when the executable wants to select a different set of libraries, and this can lead to link errors.

    For your case, where the executable is also Fortran, I recommend the above advice so that the compilation of the executable source will determine the set of libraries to use. Of course, that means that whoever builds the executable needs to know which additional options to select.

    In the case where the executable is not Fortran, the answer is less clear, as disabling the directives means that the build must add all of the needed Fortran libraries to their linker options. In such cases, it may be best to leave the directives enabled.

    There is a catch, however, in that you say some of the other projects linked in may be DLLs. In this case it is important that all projects link to the same set of libraries, or else you can get run-time errors and other misbehaviors. If the DLLs don't use MKL or OpenMP, this may be less of an issue. However, do make sure that all projects link to the DLL forms of the run-time libraries and not static libraries.