- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This suggests that you are linking to a mix of static and DLL libraries - these need to be consistent.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page