Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28385 Discussions

Link Errors with Multithreaded Runtime 64bit

Wurst__Andreas
Beginner
677 Views
Hello, I'm using Visual Studio 2017 with the Intel Fortran Compiler. I have a bigger project using several Intel libraries like mkl and I need to switch from 32bit to 64bit. When compiling in debug mode (using Runtime Library: "Debug Multithreaded (/libs:static /threads /dbglibs))" everything works fine but when compiling for release (Runtime Library: "Multithreaded") I get thousands of LNK2001 and LNK2019 errors. Compiling and linking for x86 however is possible with both runtimes. The libs that are not found are mostly mkl libs (e.g. mkl_core.lib) but also non mkl libs like libifcoremt.lib and libifport.lib. I'm guessing it has something to do with wrong path variables but I reinstalled the Intel Compiler and it should have repaired it, shouldn't it? Does anyone have an idea how to solve this problem? My Compiler Versions are 19.0.3.203 and 18.0.5.274, the problem occurs with both of them. Your help would be greatly appreciated. Thanks in advance Andreas
0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
677 Views

It looks as if you have "Mixed C Library Syndrome". Your Release application is trying to link to both static and DLL forms of the run-time library. You need to make sure that the settings for Use Runtime Library match between this project and any of the prebuilt libraries you're linking against. I note that some of them have Debug in their paths, making me suspect they are debug builds. If any of these libraries are built using C/C++, then it is extra important than the library settings match (in C/C++ this is under Code Generation).

I also noted that your release configuration has disabled optimization - was that deliberate?

View solution in original post

0 Kudos
9 Replies
mecej4
Honored Contributor III
677 Views

When you change from 32-bit to 64-bit, the MKL libraries are grouped into LP64 and ILP64 libraries, depending on whether integer arguments to MKL routines are 4-byte or 8-byte integers, respectively. You cannot simply change "x86" to "x64" or "ia32" to "intel64" in library names and command line options.

You will find it useful to use the MKL Link Line Advisor at https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor to tell you which MKL libraries to use.

0 Kudos
Steve_Lionel
Honored Contributor III
677 Views

First thing I would do is go to Tools > Options > Intel Compilers and Tools > Visual Fortran > Compilers > x64 tab, and click Reset. Then try a build. That it is also complaining about the Fortran support libraries suggests more than MKL issues.

0 Kudos
Wurst__Andreas
Beginner
677 Views
Thank you for your answers. First of all I'm very sorry for my late reply. More pressing subjects have come up. However the problem still exists. I have tried the following steps with no success so far: - Using the Reset Button you mentioned - Using another computer with freshly installed Visual Studio and Intel Compiler 18.0.5.274. - Explicitly adding "mkl_intel_lp64.lib mkl_sequential.lib mkl_core.lib" to the additional Dependencies, according to the MKL Link Line Advisor - Adding %MKLROOT% to the Include Directories (I even tried the whole path "C:\Program Files....") I'm not sure if the MKL Link Line Advisor is needed at all, as I was expecting Visual Studio to handle this according to the project settings. Also the MKL LLA doesn't differentiate between debug and non debug. Do you have any idea what else could be the problem here? Thanks again for your help.
0 Kudos
Steve_Lionel
Honored Contributor III
677 Views

In the release configuration, set the project property Linker > General > Show Progress to "Show all progress messages". Do a full rebuild of the project. Create a zip of the buildlog.htm from the Release folder and attach the zip to a reply here.

0 Kudos
Wurst__Andreas
Beginner
677 Views

I attached the build log like you requested, unfortunately it is in German. Maybe you can get the info you need anyway. 

I'll try to make an English version tomorrow.

0 Kudos
Steve_Lionel
Honored Contributor III
678 Views

It looks as if you have "Mixed C Library Syndrome". Your Release application is trying to link to both static and DLL forms of the run-time library. You need to make sure that the settings for Use Runtime Library match between this project and any of the prebuilt libraries you're linking against. I note that some of them have Debug in their paths, making me suspect they are debug builds. If any of these libraries are built using C/C++, then it is extra important than the library settings match (in C/C++ this is under Code Generation).

I also noted that your release configuration has disabled optimization - was that deliberate?

0 Kudos
jimdempseyatthecove
Honored Contributor III
677 Views

One other thing to check is in the Configuration Manager (Pull Down the x64 or Release) while in Release x64, assure that x64 is selected for all projects and assure that the Build check box is checked.

Jim Dempsey

0 Kudos
Wurst__Andreas
Beginner
677 Views

Steve Lionel (Ret.) (Blackbelt) wrote:

It looks as if you have "Mixed C Library Syndrome". Your Release application is trying to link to both static and DLL forms of the run-time library. You need to make sure that the settings for Use Runtime Library match between this project and any of the prebuilt libraries you're linking against. I note that some of them have Debug in their paths, making me suspect they are debug builds. If any of these libraries are built using C/C++, then it is extra important than the library settings match (in C/C++ this is under Code Generation).

I also noted that your release configuration has disabled optimization - was that deliberate?

Thank you very much! After some trial and error I found that one of our C++ libraries has been the problem. I'll try to recompile it with the right settings now.

Optimizations have been deactivated on purpose because we found that they impact our calculation results. This is most likely caused by some legacy code from the 1980s that doesn't hold up to modern programming standards.

0 Kudos
mecej4
Honored Contributor III
677 Views

Wurst, Andreas wrote:
Optimizations have been deactivated on purpose because we found that they impact our calculation results. This is most likely caused by some legacy code from the 1980s that doesn't hold up to modern programming standards. 

That is a more troublesome bug than the library mismatch problems reported in this thread. The root cause may be (i) one or more bugs in your code, or (ii) compiler optimizer-phase bugs. I estimate the most likely cause to item of type (i). Please consider putting together a bug-reproducer and submitting it here or to Intel Support.

0 Kudos
Reply