LINK Error LNK2005 after installing latest Win11 SDK, v26100 with Static Libraries

[publiusrgj]

  I just noticed this error linking a program of mine with the static library options:

error LNK2005: _frexp already defined in libmmt.lib(frexp_iface_c99.obj)

fatal error LNK1169: one or more multiply defined symbols found

   The static lib versions were compiling and linking fine and the only thing that changed was installing the latest Win11 SDK, version 26100. I uninstalled that, and it built fine, no such error using the previous SDK, version 22621. 

   This happens only with the static libraries, and the function "frexp" is defined in both the libucrt.lib and in one of the Intel libraries, libmmt.lib. The "frexp" function is defined in the UCRT libraries for all the versions I have installed, looks like, but something about version 26100 triggers this error. 

   With version 26100, I can force a build with the linker options "/FORCE:Multiple". The program seems to run fine, but I'm a bit leery of that. 

   I'm not explicitly calling the C lib frexp anywhere in my program, and I assume that is being referenced internally -- I'm using a few of the intrinsic Fortran functions to extract the integer and fractional point of floating point variables.  The error doesn't happen in some other programs, just this one I noticed and I assume that's because "frexp" is getting called in this one program. 

   It's a large program, and I don't where to start to try to reduce it to something small that is reproducible. 

   Question: Is there anyway to force a specific Win SDK (and toolset) version within the Intel Fortran properties page or anything? I can't see any such option in the Fortran project properties GUI in Visual Studio. If I could somehow set the version to something previous, it might work. Is there some tweak to a file somewhere that might do this? 

   And this is happening with IFORT classic, OneAPI version 2024.1. I don't think it has anything to do with Intel version, it's something that changed in the WinSDK, but I have no idea what.  I haven't tried IFX static with it. 

   Thanks. 

[andrew_4619]

You probably have some objects or libs built with an older runtime however there are other possibilities. If you do a search in the forum I am fairly sure from memory you will find a similar problems in recent weeks from others and reading those will help you.

[publiusrgj]

    Thanks. When I first got this error, I did rebuilt everything. It does depend on a module which wraps some C library functions (command line argument parsing). I rebuilt all of that. And some other Fortran programs that use the same module don't trigger the error.

   I'm going to check all the options carefully in the different configurations and makes sure there isn't some mismatch hiding somewhere. 

[Steve_Lionel · Accepted solution]

If you look in Visual Studio under Tools >Options > Intel Compilers and Libraries > IFX Intel Fortran > Compilers, you'll see a list of places it uses for searching system libraries.  One of these is represented by the "macro" $(WindowsSdkDir)" - this inserts the value of the environment variable WindowsSdkDir, which VS creates from some registry entry. 

The simple workaround is to specify the path to the desired SDK folders in the linker options for Additonal Library Directories.

[publiusrgj]

Thanks. 

I'm going to try to change the SDK version on the C static library the module depends on, which can be done easily, and see if that changes anything.  I'll have to be careful with doing that, though, as there are other things that depend on it, but for a test just to see, it shouldn't be a problem.  Then I'll try to manually change the Fortran options SDK and UCRT directory variables if necessary. 

    I tried this with a third laptop, and can confirm it's the Win11 SDK version 26100 that causes the error. Uninstall 26100 and it works fine. Install it again, and the error happens. 

[publiusrgj]

  Well, that didn't work. Didn't really think it would, cause it's the SDK version the main executable is linking against, I think. 

 Looking at the library and include paths that Steve mentioned above, I see it's the "UCRTVersion" macro (along with "UniversalCRTSdkDir") that governs this.  The "WindowsSdkDir" still points to the old Win8.1 SDK paths, well before the new Win10 SDK naming scheme.  Must be something older might depend on that or something, you know how convoluted MS stuff can get. 

    I thought it ought to be easy to define a new macro, say "OldUCRTVersion", but that's not so easy, at least with the Fortran IDE extension. The property manager thing, where you could define a new property sheet, applies only to the C/C++ stuff, looks like. 

   An environment variable might work, and I'm going to try that rather than hard-code the older UCRT version in the Fortran paths options. 

     There may be some way to override UCRTVersion, but I can't figure it out. 

[publiusrgj]

   Well, that worked. I created a new environment variable, which I named "VS22OldUCRT" (there were some other variables I noticed with names like VS19UCRT, VS17UCRT, etc. which I think are created by the Intel installer for the different developer command prompts), and set it to the previous Win11 SDK version.  

     I plugged that into the Fortran paths options, and it worked.  Now, on the C static library that a Fortran module depends on, I'll just have to make sure I've set the WinSDK version to that as well, so everything is consistent. 

    I also noticed that the path options are not global but there's one for each compiler version. I set the paths for "<latest>" version. The paths for the explicitly named versions remain the default, so that makes it easier to switch if needed. Just select the explicit last version of the compiler and you have the old default paths. 

      So, that worked to force using the older UCRT SDK version, but I'd sure like to know what changed that messed the linker up. 

[Steve_Lionel]

Those paths are defined by Visual Studio installs, not Intel. Microsoft probably moved some symbols across libraries in a way that conflicted with Intel libraries (most likely libm.lib).