Library links to Static runtime no matter what compiler options are used

[coreystraub]

Hello,

We have a library that was being built with the old ifort compiler. I am trying to update to the latest and now that ifort is gone, I am trying to switch our build over to ifx.

When I compile the library with the following commands:

ifx a.for b.for c.for /nologo /c /warn:none /Qm64 /traceback/Fo(some directory) /MD /ZI /Zi /O2 /iface:cvf

lib /nologo /MACHINE:X64 /NODEFAULTLIB /out:mylib.lib a.obj b.obj c.obj

These commands work fine but later when I try to compile our C++ project that includes mylib.lib I get the following error:
LINK : fatal error LNK1104: cannot open file 'libircmt.lib'

The project points to a directory where lib files we previously required to build (updated from the latest intel Fortran compiler install) such as libifcoremd.lib, libifportmd.lib, libirc.lib, libmmd.lib. Since most of the libraries have the md at the end it seems I would want to link against libircmd.lib but instead I am getting libircmt.lib.

The only thing I have changed is switching ifort to ifx for the command line, everything else is the same as when we compiled with ifort.

Is this expected behavior? What option would I have to add to link against libircmd.lib instead? I have been searching with no luck. Looked through ifx /help and tried a few options like /libs:dll with no luck. Any help or insight would be appreciated.

My ifx version is 2025.1.0 Build 20250317. My lib version is 14.42.34440.0.

Thank you

[Steve_Lionel · Accepted solution]

When you compile a source, the compiler adds linker directives into the object file that specify which run-time libraries to link against. I can confirm, though, that libicrmt.lib is one of these despite your asking to build against the DLL libraries (/MD does that).  I'll admit that this is a surprise to me - I too would have expected to see libircmd there. One of the Intel folk will need to respond to that.

What I can tell you is that static Fortran libraries should almost always be built with /libdir:noauto, which suppresses these directives entirely. It is then up to the executable project to specify the run-time libraries to be linked against. If it's a Fortran main, you don't need to do anything, but a C or C++ main will require you to name the specific Intel libraries needed on the link command.

If the library is C or C++ code, you can't use something like /libdir:noauto, as, unlike Intel Fortran, the C/C++ compiler generates different code depending on whether you have asked to link to static or DLL libraries.

[coreystraub]

Thank you Steve for the quick response and valuable information. I tested out the /libdir:noauto option and manually adding the run-time libraries to the project including mylib.lib from my example and everything compiled and linked. I then ran into the issue you went on to describe where once everything was linked together and I tried to register and run our main application it failed. I assume maybe if I went through and manually added all the run-time libraries to the correct projects or maybe all projects in our build then it might work but this seems excessive and hard to maintain. Although not ideal, I found adding libircmt.lib makes everything work but I have to do some more testing before I am sure. We have 6 Fortran libraries at the moment which all seem to exhibit this same behavior as I am updating them all at the same time.

I will accept your solution after I give the intel folk a chance to reply in case they have any insight or want to look into it more. I appreciate your time looking into my issue.

[jimdempseyatthecove]

>> I then ran into the issue you went on to describe where once everything was linked together and I tried to register and run our main application it failed.

Does it fail with DLL not found or some other error (e.g. crash).?

Jim Dempsey

[coreystraub]

I was able to build all the way through our code base but then I needed to register the output to be able to run our software and that is where several dlls failed to register with regsvr32. I assume because they included mylib.lib or indirectly included it through another dependency so I would need to go through those projects and add the list of run-time libraries like I did with the main project including my static fortran library. I have not had time to investigate further why regsvr32 failed so I could be wrong. If I get passed registering the output then I could try to run and see if it crashes. I will try to find some time to try this out next week and see if I can get to the point of running our application with /libdir:noauto and specifying the run-time libraries in the project.

[Steve_Lionel]

What puzzles me is that the compiler's directives for libraries to search is all DLL libraries except for this one.

D:\Projects>dumpbin -directives t.obj
Microsoft (R) COFF/PE Dumper Version 14.43.34809.0
Copyright (C) Microsoft Corporation.  All rights reserved.
Dump of file t.obj

File Type: COFF OBJECT

   Linker Directives
   -----------------
   /DEFAULTLIB:msvcrt
   /DEFAULTLIB:ifconsol.lib
   /DEFAULTLIB:libifcoremd.lib
   /DEFAULTLIB:libifportmd.lib
   /DEFAULTLIB:libircmt
   /DEFAULTLIB:libmmd
   /DEFAULTLIB:oldnames
   /DEFAULTLIB:svml_dispmd