LoadLibrary fails on Release mode

[li__andrew]

Hi, we have quite some old Fortran code built into dlls to be used in C++.  Recently we upgraded to Parallel Studio with Fortran compiler 9.1.

The Debug version of the dlls from Fortran work fine, but not the Release version.  The LoadLibrary call on the C++ side returns error 127, "The specified procedure could not be found."

Compared the dumpbin results, and found the following in Debug version but libifcoremd.dll is not in the Release build.

    libifcoremdd.dll
              10028080 Import Address Table
              1002DDB8 Import Name Table
                     0 time date stamp
                     0 Index of first forwarder reference

                  14F for_emit_diagnostic

an someone give me a hint where I should look at to find the cause?

Many thanks!
Andrew Li

[Steve_Lionel]

Wait - you "recently" upgraded to a version released more than a decade ago; one that's not even downloadable?

LoadLibrary doesn't complain about a procedure not being found, that's GetProcAddress. 

libifcoremdd.dll is the debug version of the Intel Fortran run-time DLL. I would expect a release version to use libifcoremd.dll, unless that configuration was set to link to static libraries.

I think you first need to determine exactly which call returned an error and, if it was indeed GetProcAddress, what is the exact name of the procedure you tried to load. You can then use "dumpbin -exports" on your DLL to see what names your DLL exports. It could be that your Debug configuration has different settings on the "External Procedures" property page.

[li__andrew]

Hi Steve,

Thank you for your answers!  Your opinions are most valuable. 

Sorry for my typo.  I should have said "It's upgraded from 9.1 to Intel® Parallel Studio XE 2018 with the Intel® Fortran Compiler 18.0 for Windows" :-)

You are right saying the Windows Error 127 is supposed to come from GetProcAddress.  The following is my most simple C++ testing code.  Testing the Release build of my Fortran "pvtfor.dll", the LoadLibrary returns NULL with an error code 127, without trying to invoke any specific subroutine.  However, this same 2-line testing code shows the Debug build of "pvtfor.dll" can be loaded with no issue.

HINSTANCE hDLL = LoadLibrary("pvtfor.dll");

DWORD err = GetLastError();

The copied section of libifcoremdd.dll in my post was from dumpbin of the Debug build of pvtfor.dll, the one that works.  However, its counterpart libifcoremd.dll is missing from the dumpbin of the Release build of pvtfor.dll.  This is what puzzles me.  Is it possible to miss libifcoremd.dll?  Hope someone with rich experiences like you may show me something that I don't know.

Thanks with Best Regards!

Andrew

[li__andrew]

Found a way to get by.

After changing the Runtime Library from Multithreaded Dll to Multithreaded, the issue is gone.  Still have no clue why though.

[Steve_Lionel]

Very strange. Please install DependencyWalker, run it, open your Release config DLL (built with the default setting for Runtime Library), then do File > Save As and save a .dwi file. Do the same for your Debug build DLL (save to a different .dwi). ZIp the two .dwi files and attach to a reply here.

[li__andrew]

Hi Steve, please check the attached zip file.  The dwi files of both Release ("Multithread Dll") and Debug mode are included.

Thank you!

[Steve_Lionel]

Is the release mode version one that fails to load? It does seem strange that there is no reference to libifcoremd.dll. Pleas enable the linker > Map file option, relink the Release DLL and attach a ZIP of the .map file.

[li__andrew]

Hi Steve, please find the attached file.  Yes, it is the Release build that fails loading.  Thank you!

[li__andrew]

Sorry, probably failed to attach it.  Try one more time.

[li__andrew]

Hi Steve,

Please ignore the previous upload, it's built with my modification on Runtime Library.  This attachment is the map file built with the default setting for Runtime Library, the one fails loading.

Thanks,
Andrew

[Steve_Lionel]

Your Release configuration doesn't make ANY calls into the Fortran run-time library, which is why it doesn't use libifcoremd.dll. The debug version did (for array bounds checking, etc.)

[li__andrew]

Many thanks, Steve!