Entry point sinpi could not be located in libifcoremd.dll

[spainchaud]

I have a C++ main program that calls a Fortran static library. The program builds properly, but when I try to run the release version (from Visual Studio 2019) I get the error:

"The procedure entry point sinpi could not be located in the dynamic link library C:\Program Files (x86)\Common Files\Intel\Shared Libraries\bin\libifcoremd.dll"

The file version of this DLL is 2024.1.0.0. Using the Dependencies application, I can see there is a sinpi function in the DLL. The debug version of my application runs fine.

A search of my code shows sinpi only referenced in some CUDA *.h and *.hpp files. These files are not strictly part of my code, so I don't know why it come up in the search. I suspect this fact is relevant, but I don't know how.

I assume this is a configuration problem (a clean and rebuild did not help). I have checked the debug and release properties, but I have not noticed any differences that would keep the release version from running. Any ideas on what I should be looking for?

[Steve_Lionel]

The cause of this problem is that in that in the 2024 release, Intel changed, yet again, where the compiler DLLs are installed. This wouldn't be a problem if the installer had removed the old location from PATH, but I found it did not.

Edit the system PATH environment variable to remove the folder the wrong DLL was found in.  It should have C:\Program Files (x86)\Intel\oneAPI\compiler\latest\bin and C:\Program Files (x86)\Intel\oneAPI\compiler\latest\bin32

[spainchaud]

I changed the Path variable and rebooted. The basic error message did not change, except the path to the DLL is now updated.

I am suspicious of the VC++ directories > Include Directories. The evaluated value is C:\Program Files (x86)\Intel\oneAPI\compiler\2024.2\include, but there are no files in that directory only folders. Should I be pointing to one of the subdirectories?

[Steve_Lionel]

Include directories would have no effect on this problem. Is this a 32-bit or 64-bit application?

From a regular command prompt (cmd.exe), please change directory (CD) to a folder you can write to and type:

set path > path.txt

Attach path.txt to a reply here. 

Also. what is the path to the DLL in the new error message?

[spainchaud]

The path to the DLL is "C:\Program Files(x86)\Intel\oneAPI\compiler\2024.2\bin\libifcoremd.dll". I can see that sinpi is in the DLL, but perhaps it is expecting a different argument, like a vector instead of a double. I think MKL has a version that takes a vector. MKL is used in the program.

[Steve_Lionel]

Arguments would not matter for this error. Can you attach a zip of a example project that shows the problem?

[spainchaud]

I cannot separate a single project. They are intertwined. The project that refuses to run incorporates code from at least two other projects, that I know of. The projects contain proprietary modeling code, and some of it we have to have a license to run.

[Steve_Lionel]

Let's try this. Change the project property Linker > Debugging > Generate Map of your executable project to Yes and rebuild. Open the .map file (in your Release folder) and look for "sinpi". I want to know from which object module it is referenced - a zip of the .map attached here would be helpful. It would also be helpful opening the executable in Dependencies and seeing if it complains about a missing entry point.

I still wonder about PATH issues.

[spainchaud]

I have created a map file, zipped it, and attached it. The only calls to sinpi seem to be related to MKL. 

I also opened up the exe in Dependencies, but there were no complaints of something missing. I think this is consistent with the fact that the error message only pops up when I try to run the program, not during the build.

[Steve_Lionel]

It would never show up during the build., as DLLs aren't part of a build, only their export library .LIB. Dependencies should be chasing down the references and making sure every symbol that is supposed to come from each DLL is in the loaded DLL. I know the old Depends tool did that, but it has many problems nowadays.

Did you search your system for other instances of libifcoremd.dll? I'm wondering if MKL is doing dynamic loading of DLLs.  Does the error occur as soon as the EXE starts, or can you get some way into the code before it happens? That a debug build works is interesting.

Since the reference is coming from MKL, you may want to take this to the MKL forum.

[spainchaud]

The error seems to occur before any code is read. There are lots of versions of this DLL. I found a version (19.0.1.0) at C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2019.6.324\windows\redist\intel64_win\compiler. This version did not seem to have the sinpi function. I am not sure how this relates, since the error message is very specific about which DLL is the problem.

[Steve_Lionel]

Are the 2019 folders in the definition of the PATH environment variable? I have learned not to entirely trust file paths in error messages. For jollies. rename the ones other than that named to be .dllold or something like that and see what happens.

[spainchaud]

The 2019 folders are in the PATH, by changing the extension did not solve the problem.

[Steve_Lionel]

I'm running out of suggestions. Please build and run the following program in the same environment where you get the error.

interface
function sinpi (x) bind(c)
real :: x
end function sinpi
end interface
integer :: i,ios
real :: x

print *, "Type 0 and press ENTER"
read (*,*,iostat=ios) i
if (i == 123456) then
 x = sinpi(3.0)
  print *, x
  end if
99 end

Use the command:

ifx /libs:dll sourcename.f90

What happens? (FYI - I don't know what the interface to sinpi is - I just want the program to try to load it.)

If I was still working for Intel as a support engineer, I'd ask if I could connect to your system to see what's going on, but a lot is hidden from me.

[spainchaud]

In an effort to fix the problem, I made things worse. I noted that VS2019 would always give an error message when starting. This message stated that the Intel compatibility package did not load correctly. I tried to update my oneAPI and HPC packages using the Intel installer, and it seemed to update correctly, but would only update VS2022, not letting me check the box for VS2019. After the update, the Fortran projects in my application would no longer load in VS2019.

I am now unable to create a Fortran project in VS2019. I get the message that the Intel Visual Fortran Project package did not load correctly. The "project type .vfproj is not supported in this version of the application". This means I cannot run your test program in VS2019.

I will try to move to VS2022 as I see that most of my newer Fortran projects (both IFORT and IFX) load. One older IFORT project no longer loads, but I need to remove it from the application anyway.

[spainchaud]

I have converted my projects to VS2022, and I have all the Fortran projects running again. One of the Fortran projects refused to load until I edited the project file so that it would use IFX instead of IFORT. This is strange because I have a different IFORT project that loads without problem.

I tried your test program in a command window. It compiles and runs as expected. 

[Steve_Lionel]

So, you're all set now? Maybe you had specified an IFX-only option in the project.

[spainchaud]

I am back to only having the sinpi error. Moving to VS2022 took some work because the solution used the VS2017 toolset and an older SDK. 

[spainchaud]

I have made some progress. The error message is coming from the main C++ application. This application calls a function in a static Fortran library. If I comment out the function declaration in the header, and the function call in the code, then the error goes away. I have been checking the configuration for the Fortran library and the C++ projects that call it, but I have not found the reason for the error.

[Steve_Lionel]

That's good. If I was still working, here's what I would do next. Write a minimal C++ main program that calls the Fortran routine. It's not necessary that the routine actually be called, only that it is referenced by the code - see my test program above for the idea. Build that exactly the way you build your real program and run it in that environment. Does it still fail?

If yes, then make a copy of the Fortran routine, compile it independently and specify its .obj instead of the .lib. Still fail? Start stripping out code from the Fortran routine until you have the minimal source that still shows the error. I understand that it may actually be an MKL call that is making the reference.

The other thing I would do, which I suggested earlier, is searching your entire system for libifcoremd.dll. There might be a copy in the C++ project folder structure, which would be bad. Also look for one in Windows or Windows\System - two more places it doesn't belong.

[spainchaud]

I built a console C++ project (Hello World) in VS2022. I then added the Fortran project and declared my Fortran subroutine in a header file. The program ran correctly.

I found that my original solution directly contained a subset of MKL libraries and headers, so I tried to modify the project properties to point to the oneMKL installation. To the Linker > General > Additional library directories I added $(oneMKLLibDir), and to C/C++ > General > Additional include directories I added $(oneMKLIncludeDir). Now I get build errors:

mkl_core.lib(mkl_msg_support.obj) : error LNK2005: mkl_serv_format_print already defined in mkl_intel_thread_dll.lib(mkl_intel_thread.2.dll)

mkl_core.lib(mkl_msg_support.obj) : error LNK2005: mkl_serv_file_format_print already defined in mkl_core_dll.lib(mkl_core.2.dll)

As I have already spent 3 weeks with no progress, I will attempt to rewrite the Fortran code in C++.