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

ldexp double definition libmmt.lib and ucrt.lib

Viktory
Beginner
777 Views

Dear Community,


In the last few years I have been compiling code with the 2021 HPC and Base Toolkit using the IFORT compiler and Visual Studio Community 2019.

Now I have updated to Visual Studio Community 2022 and the new 2025.0.0 HPC and Base Toolkit using the IFX compiler. When compiling now, I get the following error in the linking process:

error LNK2005: Idexp is already defined in libmmt.lib (ldexp_iface_c99.obj) in ucrt.lib (api-ms-win-crt-math-l1-1-0.dll).

The problem seems to be that both the ucrt.lib and the libmmt.lib provide an definition of ldexp.

When I tried to ignore the default libmmt.lib, the code compiled without error, but when I try to run it, I get an error that the libmmd.dll was not found. As far as I understand, this problem is related to ignoring the default libmmt.lib, as the libmmd.dll is built from the libmmt.lib.


The older 2021 version of the HPC and Base Toolkit does not have this problem.

What can I do now?


Thanks in advance for your help.

 

 

Labels (1)
0 Kudos
6 Replies
Steve_Lionel
Honored Contributor III
727 Views

This suggests that you are linking to a mix of static and DLL libraries - these need to be consistent.

0 Kudos
Viktory
Beginner
720 Views

Hi Steve,

thank you very much for youre fast reply, as far as I understand I only linked static libraries.

As you may see in my settings.png and settings2.png.

 

Or is there an other way to make sure, that i do not link dynamic libraries?

 

Greetings

Viktor

0 Kudos
Steve_Lionel
Honored Contributor III
668 Views

I don't know which libraries the MKL libraries specify in their internal linker directives. My guess is that they were built against DLL libraries. You could take this to the MKL forum for further advancement, since it is not a Fortran compiler issue.

0 Kudos
Chao_Y_Intel
Moderator
545 Views

Hi, 

From the attached picture, oneMKL library is statically linked into your code. No MKL dynamic libraries are added in this linkage line.

Perhaps there is some other place in the application introduce the dependance on libmmd.dll.

There is some tools list here, which may help you find where this dependance come from:
https://learn.microsoft.com/en-us/cpp/windows/understanding-the-dependencies-of-a-visual-cpp-application?view=msvc-170

 

thanks,

Chao

0 Kudos
Viktory
Beginner
386 Views

Hi Steve and Chao,


Thank you both for your replies. I checked the dependencies using dumpbin /dependents. There the libmmd.dll was marked as required to run if I ignored the libmmt.lib in my linking options in Visual Studio. This is correct as far as I understand, as the libmmd.dll is built from the libmmt.lib. So I can only run my executable if libmmd.dll is on my computer.

I also made a version of the code where additional mkl libraries (mkl_intel.lp64.lib, mkl_sequential.lib, mkl_core.lib) are NOT needed to compile the code as Steve suggested. When the libmmt.lib was not ignored as in my default settings, I get the same error of the same definition of libmmt.lib and ucrt.lib:

Error LNK2005: Idexp is already defined in libmmt.lib (ldexp_iface_c99.obj) in ucrt.lib (api-ms-win-crt-math-l1-1-0.dll).

So the problem is not because my extra libraries conflict, it is because the standard libraries libmmt.lib and ucrt.lib conflict.

If I use the old compiler setup, I can compile the code without ignoring libmmt.lib and then my executable is not dependent on libmmd.dll. What I have now done to solve the problem is to copy the old libmmt.lib from the 2021 setup to a directory where I have other libraries and use the old libmmt.lib when compiling the code with the new 2025.0.0 compiler setup. The code compiles and there is no error.

So there must be a problem with the standard libmmt.lib and ucrt.lib?

Regards

Viktor

0 Kudos
Chao_Y_Intel
Moderator
328 Views

thanks Viktor. I am moving this case compiler Forum to get help if this is related to standard runtime libraries.  Also do you have a test code, and compiler command line that can reproduce this problem?  that will make it much easier to further check this problem.  

regards,
Chao 

0 Kudos
Reply