- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My attempt to compile an x64 version of an inherited code that contains OpenMP directives, contains a "USE OMP_LIB" statement, and links to routines in the MKL library keeps grabbing the 32-bit version of LIBIOMP5MD.DLL.
Details about my set-up
- x64-based computer running Windows 7 Professional
- MSVS 2008 Professional (Version 9.0.30729.1 SP)
- Intel Visual Fortran 11.0.075 (yes, I know, it's old...)
- MKL 10.2.1.019
I can get the 32-bit version of the code to compile and execute. And it generates the same answers (to within roundoff) as the pre-compiled version of the code.
My problem is that I have trouble with the 64-bit version of the code. It compiles and links to libraries successfully, but throws an error when executed. A look at the executable with Dependency Walker (64-bit version) shows that the x64 executable keeps trying to load the 32-bit (x86) version of LIBIOMP5MD.DLL. Some basics:
- I have verified that MSVS is configured for x64 compilation (Visual C++ -> X64 Compilers and Tools box is checked)
- Under Project -> Properties
- Fortran -> General -> Additional Include Directories:
C:\Program Files (x86)\Intel\Compiler\11.0\075\fortran\lib\intel64;C:\Program Files (x86)\Intel\Compiler\11.0\075\fortran\mkl\em64t\lib - Fortran -> Language -> Process OpenMP Directives: Generate Parallel Code (/Qopenmp)
- Fortran -> Libraries -> Runtime Library: Multithreaded
- Linker -> General -> Additional Library Directories:
C:\Program Files (x86)\Intel\Compiler\11.0\075\fortran\lib\intel64;C:\Program Files (x86)\Intel\Compiler\11.0\075\fortran\mkl\em64t\lib - Linker -> Input -> Additional Dependencies: mkl_intel_lp64.lib mkl_core.lib mkl_intel_thread.lib libiomp5md.lib
- Fortran -> General -> Additional Include Directories:
- I have verified that libipmp5md.lib (and the .dll) exist in C:\Program Files (x86)\Intel\Compiler\11.0\075\fortran\lib\intel64
- I have verified that omp_lib.mod exists in C:\Program Files (x86)\Intel\Compiler\11.0\075\fortran\include\intel64
Interestingly enough, if I change the Runtime Library to Multithread DLL and link to either the listed libraries or their _dll versions (for the first three), then Dependency Walker tells me that the compiler has grabbed the 32-bit version of all of the additional libraries.
I can't help but think that I have screwed up a setting somewhere that I keep grabbing the 32-bit version of libiomp5md.lib. Any help would be appreciated.
Thanks.
Bruce
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You might check and clean out any references to the Intel compiler installations in the global Windows environment variables. You would want to check PATH to see that the 64-bit libiomp5.dll is found before the PATH buffer overflows.
It's not clear whether your talking about running in a build environment cmd window (start without debugging) or some other way.
If the buildlog doesn't have sufficient information about link order, you might add -# in additional command line options.
In a compiler that old, you probably had available a static libiomp5. You could force that in at the end of the link, at least temporarily to verify whether libiomp5 is the locus of your difficulty.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you suspect that your 32-bit and 64-bit libraries and DLLs have been mixed up, you can use the DUMPBIN utility with the /headers option to check. For the library, you should see something similar to
Dump of file libiomp5md.lib File Type: LIBRARY Version : 0 Machine : 8664 (x64) TimeDateStamp: 55770E5A Tue Jun 09 11:03:38 2015 SizeOfData : 00000021 DLL name : libiomp5md.dll Symbol name : ompc_set_schedule
For the DLL, similarly:
Dump of file libiomp5md.dll PE signature found File Type: DLL FILE HEADER VALUES 8664 machine (x64) 8 number of sections 55770E5A time date stamp Tue Jun 09 11:03:38 2015 0 file pointer to symbol table 0 number of symbols F0 size of optional header 2022 characteristics Executable Application can handle large (>2GB) addresses DLL
In both cases, note the "8664" and "x64". Other than that, you should expect differences between the output because I posted particulars for the files that come with IFort 15.0, not the version that you asked about.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tim--I didn't think of checking the PATH variable, but I tried to put it in the linker. I added the "...\lib\intel64" path to PATH, but that did nothing to change the issue. This is a command line executable I'm creating (in Release mode). I've been focusing on libiomp5md.dll because when I look at the executable with Dependency Walker, it tells me that the executable is trying to load the library from "...\lib\ia32" and flags it as not compatible with the remaining x64 libraries. There are a few missing libraries as well:
API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL
but my experience suggests that if I fixed libiomp5md.dll, then the rest will fall into place.
MECEJ4--I didn't suspect a mix up, but I tried what you suggested. Sure enough, the library in ia32 says it's a 32-bit version and the one in intel64 says it's 64-bit version.
Thanks to both of you anyway. I'll proceed with the 32-bit version for now, but I would like to resolve this at some point....
Bruce

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page