Error related to multiple definitions of frexp.obj when building dlls

[avinashs]

I started getting the following error while building dlls using Intel Fortran 2024.2 and Microsoft Visual Studio Community 2022 (64-bit) - Current Version 17.14.13 (August 2025) this week both with ifort and ifx:

libucrt.lib(frexp.obj) : error LNK2005: frexp already defined in libmmt.lib(frexp_iface_c99.obj)
Creating library FortranDLL.lib and object FortranDLL.exp

FortranDLL.dll : fatal error LNK1169: one or more multiply defined symbols found

I saw other posts on the same topic pointing to a changes in MSVSC related to Windows SDK file locations but do not know how to fix it. Any help would be appreciated.

The compile options are

/nologo /assume:norealloc_lhs /real-size:64 /fpconstant /fp:consistent /Qdiag-disable:10448 -Od /libs:static /threads /Qm64 /c

[Steve_Lionel]

I suggest /libs:dll and see what happens. Both of the conflicting libraries are part of MSVC.

[avinashs]

@Steve_Lionel Thanks for your response. My comments are:

1. I used your suggestion of /libs:dll and the error was resolved - the dll was built successfully. However, since I need to use the .dll in VB.net it must be built with /libs:static since /libs:dll throws an exception.

2. This appears to be an issue with the new Windows SDKs. I uninstalled the latest version (Windows 11 10.0.26100.4654) and reinstalled the Windows 10 version (10.0.19041.0) and was able to build successfully.

[Steve_Lionel]

Is the exception "entry point not found" or similar? That usually happens when there's a dependent DLL missing or not on PATH.

[avinashs]

@Steve_Lionel   Interesting question.

1. With the Windows 11 SDK, the option /libs:static failed to build the .dll with the frexp.obj error.
2. With the Windows 11 SDK, the option /libs:dll successfully built the .dll but an exception was thrown when invoked in VB.net.
3. With the old Windows 10 SDK, the option /libs:static was able to build the .dll and it worked correctly with VB.net.
4. However, the .dll built with the old Windows SDK and /libs:dll also seems to work fine with VB.net (an option I had previously not tested extensively). So regardless of the /libs option, the new Windows SDK appears to have an incompatibility.

5. I will add as a note that the Intel Fortran dll is called by a VB.net dll, which in turn is called by a third-party program that requires the VB.net dll to have COM interoperability.

[mecej4O]

The name of an object file is almost never an external symbol that is referenced from another object file. The linker reads and combines symbol tables from several object files and library files, and the linker has switches that help you find the names of needed symbols, where those symbols are referenced, etc. You may find it helpful to use these switches and pin down what is needed, etc.