Problem linking BLACS library

[avl111]

Hi,

I am trying to learn how to use MKL 10.0.012 cluster tools with Ifort 9.1. I am compiling BLACS example program Hello World (example 16-1) using the following command line:

ifort hello.f mkl_blacs_mpich2.lib fmpich2.lib

and get a bunch of "unresolved external symbol" errors in mkl_blacs_mpich2, such as e.g. "mkl_blacs_mpich2.lib(blacs_pinfo_.obj) : error LNK2019: unresolved external symb
ol _MPI_Init referenced in function _BLACS_PINFO". I assume these are resolved by linking with fmpich2.lib, which for some reason does not work for me. I am probably doing something very stupid, but can't find the answer in the MKL documentation. Any help on this is appreciated.

andrei

[avl111]

Further research showed that mkl_blacs_mpich2.lib uses mixed character case in MPI function calls, while MPICH2 libraries export names in upper case and in lower case with trailing underscore(s). Since Microsoft linker used by Intel FORTRAN does not support case-insensitive linking, I don't see how it could work at all. Has MPICH2 support with static linking ever been tested?

andrei

[mamey4]

Is there anything new on this topic? My problem right now here is similar to it.

[mecej4]

The problem (if any) is likely to be specific to the OS, the versions of IFort/ICC and MKL used. With Win7-X64, IFort 12.0.2-IA32, I had no problems compiling the example at Netlib:

[bash]s:LANG>ifort /Qmkl blacshelo.f mkl_blacs_dll.lib mkl_blacs_mpich2.lib
Intel Visual Fortran Compiler XE for applications running on IA-32, Version 12.0.2.154 Build 20110112
Copyright (C) 1985-2011 Intel Corporation.  All rights reserved.

Microsoft  Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:blacshelo.exe
-subsystem:console
"-libpath:C:Program Files (x86)IntelComposerXE-2011mklia32/lib"
blacshelo.obj
mkl_blacs_dll.lib
mkl_blacs_mpich2.lib

s:LANG>blacshelo

Process { 0, 0} (node number =           0) has checked in.

 All processes checked in.  Run finished.
[/bash]

[mamey4]

I use Win7x64, but my project is a 32bit one. I have IVF11.0.74.
The linker line that Visual Studio creates looks like this:

/OUT:"Debug\netlib.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Program Files (x86)\Intel\Compiler\11.0\074\fortran\mkl\ia32\lib" /MANIFEST /MANIFESTFILE:"D:\Software\Code\netlib\netlib\debug\netlib.exe.intermediate.manifest" /DEBUG /PDB:"D:\Software\Code\netlib\netlib\debug\netlib.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"D:\Software\Code\netlib\netlib\debug\netlib.lib" mkl_blacs_mpich2.lib mkl_blacs_dll.lib

I don't see the thing that makes this one different from yours. The only difference would be that you have version 12 and I version 11 of the compiler. But I really can't imagine that MKL would be distributed with the v11 compiler if such a simple program wouldn't work with it.

[mecej4]

I'm also running the 32-bit compiler; however, 11.0.074 is over a year old.

Try changing the order of the libraries to

mkl_blacs_dll.lib mkl_blacs_mpich2.lib

instead of

mkl_blacs_mpich2.lib mkl_blacs_dll.lib

[mamey4]

Hey, that did the trick, thanks :-) Although I don't quite understand why.
If, in another project, furthermore I want to use mkl_scalapack_core.lib and some libraries for MPI; how do I know in which order I have to call them? The try-and-error-option could be pretty gruesome if a greater number of libs are used.

[mecej4]

Try to use the MKL Link-Line-Advisor -- it is usually sufficient for most purposes.

Most linkers search libraries in the order listed in the command. So, things are easy as long as routines in one library do not call routines in a library that was listed earlier.

If Library-A needs routines from Library-B and vice versa, it gets more complicated. In such cases, you may need to list one or more of the libraries more than once.

Alternatively, you can build a custom library by combining the contents of more than one library.

[mamey4]

I finally managed to link all of my libraries - it actually was an issue of reordering the libs in the linker command. The strange thing is: in my project I linked MSMPI and BLACS, using on the on hand msmpi.lib and msmpifec.lib, and on the other hand mkl_blacs_dll.lib and mkl_blacs_mpich2.lib. So the MPICH2-compatible version of BLACS seems to be able to work together with the MSMPI libs. However, I don't want to use dynamic binding, so I'd like to remove the mkl_blacs_dll.lib dependency. But when I do that, suddenly the linker again finds a number of errors, related to the MPI calls in mkl_blacs_mpich2.lib.

[mecej4]

I'd like to remove the mkl_blacs_dll.lib dependency. But when I do that, suddenly the linker again finds a number of errors

That is to be expected. A DLL does not contain unsatisfied externals because the linker is not going to process it while linking your program, using instead the import library. All external symbols must be either within the DLL itself or in other DLLs that the first DLL depends on (and maintains relocation/redirection tables for).

A static library, on the other hand, almost always contains unsatisfied externals, unless it is the C/Fortran RTL itself.

[mamey4]

Alright, I finally managed to get rid of the dll dependency. I had to link to mpi.lib of the MPICH2 library in order to resolve the linker errors I described. This leads me now to the point that my test application works, but it is linked to both MSMPI and MPICH2 libraries. Not pretty, but right now it's the best I can get.