Multithreaded vs Multithread DLL

[Calvin_D_R_]

     The following problem, involving "Multithreaded" vs. "Multithread Dll" Runtime Libraries, is not critical to anything I'm doing, but my curiosity is aroused.
     The program is written in .f90 code developed and compiled with MSVS Professional 2013 with Intel Parallel Studio XE 2015 Update 4 Composer Edition For Fortran Windows*. It "USE's":lapack95, OMP_LIB and two homemade MODULE's.

     The Fortran Project Properties, Command Line reads:
/nologo /O3 /QxHost /Qparallel /heap-arrays0 /Qopt-matmul/Qopenmp /real_size:64 /Qfp-speculation=safe/module:"x64\Release\\" /object:"x64Release\\"/Fd"x64\Release\vc120.pdb" /check:none /libs:static/threads /Qmkl:parallel /c

     The program compiles and runs without errors or warnings on my PC#1, with an i7-860 CPU, running Windows 7 Ultimate SP1.

     If, however, I copy the entire project into my PC#2, with an i7-4770 CPU, running Windows 7 Professional SP1, compilation fails, giving the errors:

Error 2  error LNK2001: unresolved external symbol__intel_lib_iob_func libifcoremt.lib(for_diags_intel.obj)
Error 3  error LNK2001: unresolved external symbol__intel_lib_iob_func libifcoremt.lib(for_nt_open_proc.obj) 
Error 1  error LNK2019: unresolved external symbol__intel_lib_iob_func referenced in function for_pause libifcoremt.lib(for_pause.obj) 
Error 4  fatal error LNK1120: 1 unresolved externals x64\Release\SCF-MO-GTO.exe

If I change the Fortran Project Properties, Fortran:Libraries:Runtime Libraries from "Multithreaded" (ie Static) to "Multithread DLL" (ie Dynamic), the program compiles and runs on both PC#1 and PC#2 without errors. So long as I run the program in the VS2013 IDE ("Start Without Debugging") I do not need to provide access to any .dll's. If I run 'outside' of the IDE, I must make the following five dll's available in the folder with the program .exe:

mkl_rt.dll; mkl_core.dll; mkl_def.dll; mkl_intel_thread.dll; mkl_mc3.dll

My question, of course, is why does the program, with "Multithreaded", compiles and runs o.k. on PC#1, but not on PC#2. VS2013 and Intel Parallel Studio 2015 were installed on both machines with the same installation packages and the same options, SFAIK.

Don

[Steven_L_Intel1]

That symbol should be defined in libirc.lib, part of the compiler support library. The reason the DLL version works is that this "iob" functionality is handled a different way (it's a C thing). Try setting project property Linker > General > Show Progress to "Show all progress messages" and see whether the correct libraries are being searched (easiest to open the buildlog.htm and search). Maybe you've got the VS environment on the other PC set for an older Fortran version?

[Calvin_D_R_]

Steve:
     SFAIK, the installations of both Composer XE 2015 and  VS2013 were the same on both machines. Also, note that on PC#2, the program with Multithread DLL compiled and ran under the IDE without my having to furnish access to the dll's. Doesn't that indicate that VS is finding the correct libraries and dll's?

     I did as you suggested, with "Multithreaded", on both machines. Wow!! ... those are long buildlog.htm files! I won't claim to have made a line-by-line comparison of the two files, but I'm pretty sure that all of the lines starting with "Searching" are identical, with /.../Composer XE 2015/... for all of the Fortran files.

     On PC#2, the file continues to "Finished searching libraries", "Invoking cvtres.exe"+a few lines, "Adding resource....", then "Unused libraries"+paths of 8 .lib files. That is immediately followed by the 4 error messages that I posted previously.

     On PC#1, after the list of "Unused libraries" (which is the same list as on PC#2) there are a large number of lines beginning "Discarded", then one beginning "Selected symbol", then one line beginning '.xdada'. That is followed by "Replaced symbol(s)" and many lines of '.xdata'. The sequence of "Selected symbol" --- "Replaced symbol(s)" repeats quite a few times. That is followed by "Starting pass 2", many lines, then "Finished pass 2", "Embedding manifest" ....

     Does any of that provide a clue?
     Thanks for your help.

Don

[Steven_L_Intel1]

Not really - please zip up the two logs and attach them here.

[Calvin_D_R_]

Steve:

See attached.

Don

[Steven_L_Intel1 · Accepted solution]

Thanks.

Would you please ZIP up the libirc.lib and libifcoremt.lib from C:\Program Files (x86)\Intel\Composer XE 2015\compiler\lib\Intel64\ on the two systems and attach it here?

[mecej4]

The six source files in the zip file do not make any calls to MKL routines, so the troubleshooting can be simplified by removing all references to MKL libraries and DLLs.

[Calvin_D_R_]

Steve:
     Pardon me for jumping ahead of your instructions, but the problem appears to be solved with the help of your last post.
     Since libifcoremt.lib is mentioned in all three basic error messages, I had already compared date, size, and details of that file on the two computers. They looked o.k.
     At your mention of libirc.lib in your last post, I checked that ... and they were NOT the same date nor size on the two computers. Replacing the one on PC#2 with a copy of the one on PC#1 allowed the program (with Multithreaded) to compile and run on PC#2 without error.
     The 'bad' libirc.lib on PC#2 is dated 1/22/15 and has a size of 530 KB, while the one from PC#1 is dated 4/18/15 and has a size of 533 KB. The latest installation package used on both machines is w_fcompxe_2015.2.179.exe. There are a number of other .lib files in the ...\Composer XE 2015\compiler\lib\Intel64\ on PC#2 (but NOT on PC#1) with the 1/22/15 date.
     Just out of curiosity, I'm going to uninstall all versions of Intel Fortran on PC#2, then reinstall the latest one.
     What tipped you off to the libirc.lib file?
     Unless you tell me otherwise, I'll assume that there is no need for me to post the files you asked for in your last post.
     Your high level of expertise, and your willingness to share it, are greatly appreciated.

Don

[Calvin_D_R_]

mecej4:

     You are, of course, right. After removing mkl_rt.lib from the linker line, the program still compiles and runs fine.

It was not previously clear to me that lapack95 and/or blas95 did not require that. Thanks for your input.

Don

[Steven_L_Intel1]

What tipped me off is that the symbol in question is defined in libirc.lib, but you seem to have a mix of libraries from update 2 and update 4 on the problem PC (at least that's how it looked to me.) Making these consistent will resolve the problem, and no, I don't need to see the files I asked for.

[mecej4]

Calvin D R. wrote:

mecej4:

     You are, of course, right. After removing mkl_rt.lib from the linker line, the program still compiles and runs fine.

It was not previously clear to me that lapack95 and/or blas95 did not require that. Thanks for your input.

Don

If you had placed any calls/references to lapack95 or blas95 routines from your codes, you would have needed to tell the linker to use the corresponding MKL_xxx95 libraries and mkl_rt.lib.

You have a "USE lapack95" in one of your sources that can be removed.

[Calvin_D_R_]

mecej4:
Now I'm confused (again/still?).

The project has PROGRAM MainSCF with Use lapack95; Use Integrals; Use SCF_utils; and USE OMP_LIB.

MODULE SCF_utils has Use Integrals; and Use Lapack95.

MODULE Integrals has no USE statements.

Both PROGRAM MainSCF and MODULE SCF_utils contain calls to the lapack95 SYEVD routine.

After your first message, I removed mkl_rt.lib from the Project Properties:Linker:General:Additional Library Directories and ....:Input:Additional Dependencies. The project compiles and runs without errors.

So, what do you mean when you say "If you had placed any calls/references to lapack95 or blas95 routines from your codes, you would have needed to tell the linker to use the corresponding MKL_xxx95 libraries and mkl_rt.lib."??

b.t.w.: On PC#2, uninstalling all Intel Composer versions, then reinstalling only the latest XE 2015 Update 4 did result in clearing the 'bad' .lib files.

[mecej4]

In any subprogram that makes calls to Lapack95/BLAS95 routines, you need USE statements since explicit interfaces are required for most of these routines. For the remaining MKL routines, providing interfaces (with USE statements or otherwise) is optional.

Adding USE statements when they are not required is not going to impact the success of the build, but may add confusion and may slightly slow down compilation.

Lapack95/BLAS95 depend on the base MKL libraries. Therefore, if you have a needed USE ...95 in your sources, that is an indication that you will have to link with the base MKL libraries. Lapack95 provided just a simplified interface to the old-style (Fortran 77) Lapack libraries. Similarly with BLAS95.

As of now, your source files do not need any part of MKL or BLAS (there is no call to ?SYEVD. I built and ran the program without having to use MKL). When you do, you may find it helpful to use the MKL Link Line Advisor at https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor .

[Calvin_D_R_]

mecej4:

I very much appreciate your input but I'm still not understanding. My program DOES have several repeated calls to SYEVD, yet, it does NOT require mkl_rt.lib.

Don

[mecej4]

Don, sorry, I confused this thread with another. In fact, you have not posted any source code, so I should not have said anything about what was in or not in your sources!

[Calvin_D_R_]

mecej4:

Don't worry about it. Trying to understand your comments caused me learn a few things that I should have learned anyway.

Don