Entry point could not be located

[Chestnut]

I have a question about using DLL.

We distribute executable files and three DLL files to our users. The DLLs allow the users to modify the subroutines and link these subroutines with our main program.

Our compiler version is:
Intel(R) Visual Fortran Composer XE 2012.

One of our uses Visual Studio 2019 Community and Intel oneAPI Base+HPC Toolkit. He modified one of the subroutines and recompiled its DLL file. When he rerun the program with the updated DLL, he got the following error message:

"Main.exe - entry point is not found
Procedure entry point for_realloc_lhs is dynamic link library;
it is not found in C:\..\..\..\*.dll."

We checked his *.vfproj file and we did not find any difference from ours.
What caused this error message? How to fix it?

In the future, how do we prevent this kind of error? Our compiler and our users' compiler will always be different.
This means that our compiler could be an older or newer version compared to the ones of our
users.

Thank you, Xuemei

[Steve_Lionel]

It is a general rule that the run-time libraries be at least as new as the version the application was built with. Intel provides free downloadable installers for the compiler libraries. However, DLLs you build with an old version should continue to work - unless...

Unless you did something very bad and either provided outdated Intel compiler library DLLs or, worse, built your DLL with the Intel libraries linked in and with the symbols exported, so that the user's code is looking for Intel entry points in your DLL. I really hope you're not doing that, but I've seen it before.

I do find the DLL path in the error message puzzling - did it really display exactly that text, or did you modify it?

The more likely answer is that you installed the 2012 DLLs along with yours, not using the Intel redistributable installer, and Windows found them in PATH before the correct ones. It may be that there are multiple copies of libifcorert.dll on the user's system - the correct ones and the ones you provided, and PATH has both folders but the wrong one first. The old Intel DLLs should be removed and PATH edited to point to the ones installed by the compiler.

[Chestnut]

Hi Steve,

Thanks for your prompt reply.   Attached is the error message sent from the user.  I did modify the path. 

If this is indeed libifcorert.dll issue, how can he determine which is correct and the right path? 

Thank you,  Xuemei

[Steve_Lionel]

That Windows is looking for that entry point in newmodes.dll suggests to me that the "very bad" situation I described is in fact what happened. There's no good reason for Windows to be looking for for_realloc_lhs in newmodes.dll. Is that your DLL?

I would be interested in seeing a link map of newmodes.dll. You have to enable this in the project settings for Linker.

[Chestnut]

What is the  link map of newmodes.dll?    I should turn on 'yes' from  the "link library dependencies"?  I attached a screenshot.

After I compile the DLL file, where can I find the link map and how do I know if this is correct?    Our user compiled the DLL file and got the error message. I need to understand it before I give him the instruction.   Thanks you 

[mecej4]

In your project Property Pages, navigate to Linker-Debugging, and set "Generate Map File" to "Yes". You can give the map file a name of your choosing, or accept the default name. Alternatively, in the Linker-Command Line panel, add /map .

[Chestnut]

Thank you so much for helping.

Attached are two map files from our user.  We distribute our main app with several DLLs that our users can modify on their own.  When our user modified  GEOMXACT.DLL, it works with our main app. However,  the error message is from their modified NEWMODES.DLL with our main app. Our user says that he uses the same procedure to compile these two DLLs.

Please check the map files and let me know what went wrong.

Thank  you, Xuemei

[mecej4]

Only one of the two map files shows an entry for the RTL routine for_realloc_lhs. Old versions of libifcoremd.dll did not export for_realloc_lhs. Steve_Lionel's diagnosis probably applies, if you substitute "libifcoremd" for "libifcorert".

On the system where the "for_realloc_lhs ... not found" message is issued when your application is run, check the execution path and make sure that the new libifcoremd.dll is found in %PATH% before the old version.

[Chestnut]

Thanks!  This is puzzling.

We distributed the main app and three *dlls, including newmodes.dll and geomxact.dll.  The user runs the apps without any issues. Then he recompiles these two dlls to fit his needs.  Both dlls are compiled in the same environment. 

When he replaces our geomxact.dll with his updated geomxact.dll, the app runs OK.  But when he uses his newmodes.dll, the app runs with the error message.   How can one of the dll map shows an entry for the RTL routine for_realloc_lhs but  not the other?