ERROR: entry point _erfq could not be located in libifcoremdd.dll

[bmchenry]

Question: Has a windows 8.1 update recently (like last 3 days?) somehow adversely affected the Dynamic Link for debug compilations? I have a large solution with 4 projects, (EXE & 3 DLLs) compiling/running in Win8.1., Ia32, Visual Studio 2010, w_fcompxe_2015.5.280 all latest greatest. (i have and use 2016 and may see if it occurs in that but this project already distributed w/2010 so delaying having to update redistro libraries)

For some reason TODAY started throwing the error 'The procedure entry point _erfq could not be located in the dynamic link library C:\.....\redist\ia32\compiler\libifcoremdd.dll  when i try to run in debug or 'run w/o debug' the compiled debug program.

However a release compile also done today works fine and debug worked fine up until today (and no changes, even reloaded a week old version from backup  to test and got the same error on debug version only). Could a recent (past week) change in MS update have changed the linker to cause this?

Will try the trusty ole 'full reboot system' to see if something corrupted (been a day or so since full reboot) but sending it out to see if anyone else sees some new error like this thrown when you execute a debug compilation?

any clues to cause/solution will be appreciated.

Thank you!

brian

[bmchenry]

Another clue: The prior error was with/Fortran compiler 16.0.0.110[IA32] , so i changed to prior version 15.0.5.280[IA32], and the message became 'Entry Point not found 'the procedure entry point _logq could not be located from library ...\redist\ia32\compiler\libifcoremdd.dll

different entry point from _erfq to _logq (and thats GQ lower case). Anyone familiar with either of these entry points?

i would guess this is a debug linker issue (since all works fine in release mode)

It appears related to some update to Win 8.1?? since i have not changed the installation (guess i will go through the latest updates and backtrack them) and now it's having issues.

any clues/ideas will be appreciated

Thanks

[Steven_L_Intel1]

Something is very odd here. Both of those entry points are in libmmdd.dll, not libifcoremdd.dll. Would you please set the project property Linker > General > Show Progress to "Show all progress messages", rebuild the program and then attach a ZIP of the buildlog.htm to a reply here? I can't imagine how Windows would be looking for those in libifcoremdd.dll.

[mecej4]

I ran this small program to locate the library/DLL in which the ERF intrinsic is implemented.

program xerf
real x
real(kind=8) :: y
real(kind=16) :: z
x=1.0
y=1d0
z=1q0
print *, erf(x)
print *, erf(y)
print *, erf(z)
end

Here is a portion of the map file produced:

 0001:00001622       erff                       0000000140002622 f   libmmd:libmmd.dll
 0001:00001628       erf                        0000000140002628 f   libmmd:libmmd.dll
 0001:0000162e       __erfq                     000000014000262e f   libmmd:libmmd.dll
 0002:000001e0       __imp_erf                  00000001400041e0     libmmd:libmmd.dll
 0002:000001e8       __imp_erff                 00000001400041e8     libmmd:libmmd.dll
 0002:000001f0       __imp___erfq               00000001400041f0     libmmd:libmmd.dll

I suspect that you built the application with a mismatched set of libraries. In other words, the import library is for a different version of the DLL than the DLL that is found at execution time.

[bmchenry]

Thank you both!

I had just ran dependency walker on the debug and found LIBIFCOREMDD>DLL & LIBIFPORTMD.DLL are loaded as 64 bit. Not sure how that change came in since as i mentioned i have been running in Release and DB for weeks since the last INTEL update and so it must be related to something in a Windows update? since how would they randomly change to 64bit? (I am compiling in IA32 and haven't used 64)

Thank you both and i will post up once solved (since i think that must be it!)

brian

[Steven_L_Intel1]

No - Dependency Walker doesn't follow the Windows rules for loading DLLs. Those routines are not expected to be in libifcoremdd.dll at all.

[bmchenry]

Steve,

I have sent a zip file direct. Thank you both for your assistance.

[Steven_L_Intel1]

First of all, Windows update would have no relation to this. I see you are linking against Winteracter, which may be improperly built. I see no references to these symbols in your own code, and you're linking statically so you're not referencing the DLLs yourself. winter.lib, or maybe one of the other libraries you link to, might be.

You could search the Dependency Walker output for "erfq" and see where it is being referenced.

[bmchenry]

Hi Steve,

been using winteracter for a long time without any issues and again, all was working fine working in release and debug until this week? I will loo for where erfq is coming from. Thanks for taking a look.

[bmchenry]

Just a note that i haven't figured it out yet but i believe it is related to something i installed recently (unrelated to Fortran/Linker) which has messed up an environment path such that the linker is picking up a older/different version of a library. I uninstalled the intel fortran 64 thinking that might fix it. Nope.

I'm needing to work on some other things right now but will post up once i figure out the solution (and another clue is single exe's solution/projects still work fine in DB and Release with recompilation, it is only this large EXE and 3 DLLs linked project that won't start up in Debug (it works fine in release) Thanks for all the clues and assistance and will let you know (hopefully it won't be a D'Ohhhhh Homer Simpson type moment ;-) but then again, whatever it is, i'll take it to be fixed!)

[Steven_L_Intel1]

Here's something you can try that may make it easier. After you reinstall Fortran, open a Fortran command prompt environment for x64 and run DependencyWalker (the 32-bit one). Now "open" your executable in DependencyWalker and see what errors it finds.

[bmchenry]

the saga continues...had other projects like t-day activities and so got back to it today. A summary of the issue is as follows:

• a couple weeks ago the Fortran compiler (2015 update 5) would not run in Debug mode. it had been working fine for months.
• i also had 2016 release in MSVS 2016 and it also started having issues ONLY when running in debug mode
• This particular program runs fine in Release and Debug compilation: it is a main exe with a few DLLs
• the error/problem is with the startup in debug mode in MSVS and IVF.
• today i spent time and uninstalled the 64 bit compiler and then all compilers and tried various combinations
• Also saw there are debugger issues and need to install the redistro of 2012 (see below release note section) for systems w/o 2012 (i have MSVS 2008, 2012, 2013) i have installed that per the release notes.
• The program has run fine in debug mode for a long time. This is a new issue that cropped up ONLY when i try to start in debug mode from MSVS.i get 'entry point could not be located' as it searched in the dll
• to further complicate things it throws a different item for each compiler/MSVS version:
• MSVS 2008 w/IVF 2013 SP1 throws _ynq
• MSVS 2012 w/IVF 2015 update 5 throws _logq
• MSVS 2013 w/IVF 2016 release throws _erfq
• it throws the error before any breakpoint can happen
• The debugger is looking in libifcoremdd.dll for these entries

any idea how to trace/determine the source of the error? Like what missing library which contains these apparently GNU related calls

• I note GNU items are installed for X64 debugger and i have tried with and without X64 and same error occurs
• I would guess it is a library link/ path/ issue and the debugger is not finding a library it needs for these GNU related function

Thank you for any clues/ideas of how to resolve this and get the debugger once again working properly.

[bmchenry]

FIXED! or at least back working! Thank you mecej4! for givig me the clue to the library where these entry points are found

i simply copied libmmd.dll from redist/ia32/compiler to the debug Output directory and now the MSVC starts up in debug and functions as expected.

not sure why it wasn't' picking it up from c:\Program Files (x86)\Intel\Composer XE 2015\redist\ia32\compiler where it resides (as well as other places) however now that it's working solution of that puzzle will wait until i get a few other things completed.

[Steven_L_Intel1]

Please do this:

In the Windows search box enter "cmd.exe". When you see the application appear, click on it. (Don't use one of the preset command line shortcuts other than the generic Windows Command Prompt for this.)  Type:

set path > C:\path.txt

(You can change the location to any writable folder you like).

Attach path.txt here.

My guess is that you don't have PATH correctly set up. It should be finding the DLL in a subfolder of C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist

[bmchenry]

Hi Steve,

attached is the path.txt file. What a mess! (oh how i long for the days everything was contained in a local directory! NOT!)

i had thought this was the probable source and so as i mentioned in the thread i uninstalled all IVF and MSVS and then reinstalled. I wonder if the path gets changed/scrambled during installation/uninstall and due to the different locations for 2008, 2010 & 2013 libraries forMSVS and IVF 2013, 2015, 2016. (and whether the order of installation of the various MSVS and IVF might make a mess) Interesting that the error in entry point for libifcoremdd.dll is in the same location as the libmmd.dll which should have been searched for the entry point. The location being: c:\Program Files (x86)\Intel\Compser XE\redist\ia32\compiler

Thank you for your assistance and all your contributions to this great forum.

brian

[Steven_L_Intel1]

I've seen worse. I don't spot anything in here that implicates the problem you had, but you can remove the following folders from PATH. (Note that in the setting for PATH you may see %INTEL_DEV_REDIST% as part of the path):

C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\mpirt; (appears twice)
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler; (appears twice)

The newer versions of these are under ia32_win.

[bmchenry]

below is the PATH from

Control Panel->System->Advanced System Settings->Environment Variables->System Variables->Path

which as you expected has the %INTEL_DEV_REDIST%, it also has ia32 and ia32_win (um...isn't ia32 windows??),  I note in bold the duplicates and will remove them

Windows complaint: Why does the Environment Variables dialog and Edit (like Edit Path) of Advanced system setting have such a primative display which requires a copy edit/paste to an external editor to look at/edit (see below, I used www.textpad.com to edit/etc)

Just a FYI and as you said, this probably isn't the source of the issue but will edit to remove duplications

Thanks for the check on PATH

brian

%INTEL_DEV_REDIST%redist\ia32\mpirt;
%INTEL_DEV_REDIST%redist\ia32\compiler;
%INTEL_DEV_REDIST%redist\intel64_win\mpirt;
%INTEL_DEV_REDIST%redist\ia32_win\mpirt;
%INTEL_DEV_REDIST%redist\intel64_win\compiler;
%INTEL_DEV_REDIST%redist\ia32_win\compiler;
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\mpirt;
C:\ProgramData\Oracle\Java\javapath;
c:\wint\bin;
C:\Program Files (x86)\Intel\Trace Analyzer and Collector\9.0.1.035\bin;
C:\Program Files (x86)\Intel\MPI\5.0.1.037\intel64\bin;
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler;
C:\Program Files (x86)\Intel\iCLS Client\;
C:\Program Files\Intel\iCLS Client\;
C:\windows\system32;
C:\windows;
C:\windows\System32\Wbem;
C:\windows\System32\WindowsPowerShell\v1.0\;
C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;
C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;
C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;
C:\Program Files (x86)\Lenovo\Motion Control\;
c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;
c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;
c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;
C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;
C:\Program Files (x86)\Common Files\Intuit\QBPOSSDKRuntime;
c:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\;
C:\Program Files (x86)\Common Files\Plantronics\;
C:\Program Files (x86)\Plantronics\Spokes3G\;
C:\Program Files (x86)\Skype\Phone\;
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;
C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;
C:\Program Files (x86)\QuickTime\QTSystem\;
C:\Program Files\Intel\WiFi\bin\;
C:\Program Files\Common Files\Intel\WirelessCommon\

[Steven_L_Intel1]

ia32_win and intel64_win are new in the 2016 products. I think this was done because we have C++ compilers that target other platforms, such as Android.) But the old PATH entry should have been removed.