This application has failed to start because libifcoremd.dll was not found. Re-installing the application may fix this problem

[turkeydodo]

The error message pops out when I click on "Start Debugging".

Iam using IVF 10.1with Visual Studio 2005.My code is linked to3 Hypermesh libs "hmin.lib hmreslib.lib hm.lib". The compile option used is "Multithread DLL (/libs:dll /threads)". I can not use "/libs:static" because it gave me many error messages which means the 3Hypermesh libs are dll libs. The code has successfully compiled and linked but can not run. Also, I am using x64. I tried both debug mode and release mode. They are all not working!

[Xiaoping_D_Intel]

Would you please check ifthe path to libifcoremd.dll is included by your PATH environment variable? I tested 10.1.030 and found no such error. Normally the compiler installation program will update the environment variable setting automatically.

[turkeydodo]

I found"libifcoremd.dll" in C:\Program Files (x86)\Intel\Compiler\Fortran\10.1.030\em64t\Lib

So I add above folder name to the following PATH location

MVS->Tools->Options->Intel Fortran->Compilers->Libraries:

Now the Directory List like

$(IFortInstallDir)Lib
$(VCInstallDir)atlmfc\lib\amd64
$(VCInstallDir)lib\amd64
$(VCInstallDir)PlatformSDK\lib\amd64
$(FrameworkSDKDir)lib\amd64
V:\Windows\FlareTestCases\Ken
C:\Program Files (x86)\Intel\Compiler\Fortran\10.1.030\em64t\Lib

But it still does not work!

[Xiaoping_D_Intel]

"MVS->Tools->Options->Intel Fortran->Compilers->Libraries" PATH is for building the application not for running.

The place to update the system PATH environmentis "Control Panel -> System Properties -> Advanced -> Environment Variables"

[turkeydodo]

Thanks! It works! PATH enviornment variable is not automatically generated after installation in my machine.

However,I got a new issue. In the running, I got the error message

"Unhandled exception at 0x0000000140066772 in console1.exe: 0xC0000005: Access violation reading location 0x000000000000004c"

After I debug, I found that the error occurs at the underline in the following subroutine

SUBROUTINE whmsub1(nsub,nsid)
cDEC$ ATTRIBUTES C, ALIAS:'HMRES_simulationcreate' :: HMRES_simulationcreate
cDEC$ ATTRIBUTES C, ALIAS:'HMRES_simulationopen' :: HMRES_simulationopen
character*20 scase
integer nsub,nsid,err
nsid=1
scase="LOOP 1\0"
err=HMRES_simulationcreate(scase,nsid)
err=HMRES_simulationopen(scase,nsid)
return
end

The function "HMRES_simulationcreate()" is aC language function provided by Hypermesh. So here, we use ATTRIBUTES command for mixed language. The function is declared inthe head file "hmreslib.h" as

int HMRES_simulationcreate(char *simulationname, int simulationid);

I am wondering if my compile options and link options are right or not. The compile option are:

/nologo /Zi /Od /gen-interfaces /extend_source:132 /warn:interfaces /module:"x64\Debug\" /object:"x64\Debug\" /traceback /check:bounds /libs:dll /threads /c

The link options are

/OUT:"x64\Debug\Console1.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"V:\Windows\FlareTestCases\Ken\NewKen" /MANIFEST /MANIFESTFILE:"V:\Windows\FlareTestCases\Ken\NewKen\Console1\Console1\x64\debug\console1.exe.intermediate.manifest" /DEBUG /PDB:"V:\Windows\FlareTestCases\Ken\NewKen\Console1\Console1\x64\debug\console1.pdb" /SUBSYSTEM:CONSOLE /STACK:20000000 /IMPLIB:"V:\Windows\FlareTestCases\Ken\NewKen\Console1\Console1\x64\debug\console1.lib" hmin.lib hmreslib.lib hm.lib

The code already pass the compile and link. But when it is running and tries toacces outside libs and fails with access violation.

[IanH]

Often this issue is due to a mismatch in calling conventions. I think 10.1 included the C interoperability feature of F2003. If you can use this it often makes getting the calling conventions right much easier. I'd suggest something like (apologies for any syntax errors):

[fortran]SUBROUTINE whmsub1(nsub,nsid)  
  USE ISO_C_BINDING, ONLY: C_NULL_CHAR
  IMPLICIT NONE
  
  character(20) scase
  integer nsub,nsid, err
  
  INTERFACE
    FUNCTION HMRES_simulationcreate(scase,nsid) RESULT(err)  &
        BIND(C, NAME='HMRES_simulationcreate')
      IMPLICIT NONE
      USE ISO_C_BINDING, ONLY: C_CHAR, C_INT
      CHARACTER(KIND=C_CHAR), INTENT(IN) :: scase(*)
      INTEGER(C_INT), INTENT(IN), VALUE :: nsid  
      INTEGER(C_INT) :: err
    END FUNCTION HMRES_simulationcreate
    
    ! ...and again, for HMRES_simulationopen...
  END INTERFACE
  
  nsid=1
  scase="LOOP 1" // C_NULL_CHAR
  err=HMRES_simulationcreate(scase,nsid)
  err=HMRES_simulationopen(scase,nsid)
  return
end
[/fortran]

(There is the implicit assumption in the above that C_INT and C_CHAR are also the default integer and default character kinds respectively. If that's not the case then the compiler may complain.).

If you call lots of HMRES_* functions, I'd be tempted to create a separate module with all the interfaces spelt out, and then you can pull that in as required using a USE statement.

If you can't use features from modern fortran, then I suggest creating interface blocks that spell out the type and reference/value attributes (using all that !DEC$ stuff) for the functions.

[turkeydodo]

It works! Thank you vey much!

[turkeydodo]

New issue in FORTRAN calling C function used in Hypermesh.

The C function defined in Hypermesh is

typedef unsigned int HM_entityidtype;
int HMRES_valueadd(HM_entityidtype id, double value);

How to code these two lines in INTERFACE? HM_entityidtype isa new type, how can I declare using TYPE?

Thanks!

[IanH]

The typedef just means that HM_entityidtype is a synonym for unsigned int. Fortran doesn't have unsigned integers, but using INTEGER(C_INT) on the fortran side will work unless you actually do some arithmetic operations on the variable.

[TimP]

If value is expected, you can get away with omitting it only when C_INT happens to be the same size as a pointer (as on 32-bit OS), in addition to not operating on it.

[turkeydodo]

Thanks a lot! It works where I just use INTEGER(C_INT).

I met a new issue. Because I use the compile option "/libs:dll /threads". When I tried to run the generated *.exe file inother machines without IVF installed. I got the error message

"This application has failed to start because libifcoremd.dll was not found. Re-installing the application may fix this problem."

This maybe a typical issue for distribution. How to solve that?

So I tried to compile using the option "/libs:static". But at once I got the error message

Description File
error LNK2005: sprintf already defined in LIBCMT.lib(sprintf.obj) MSVCRT.lib
error LNK2005: fopen already defined in LIBCMT.lib(sprintf.obj) MSVCRT.lib
......

A long list shows that some functions already defined and conflicted with other libs. So I check the web and find the link

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q148/6/52.asp&NoWebContent=1

I follow the instruction below:

Solution One: Force Linker to Link Libraries in Correct Order
1. On the Project menu, click Settings.
2. In the Settings For view of the Project Settings dialog box, click to select the project configuration that is getting the link errors.
3. On the Link tab, click to select Input in the Category combo box.
4. In the Ignore libraries box, insert the library names (for example, Nafxcwd.lib;Libcmtd.lib). Note The linker command-line equivalent in /NOD:.
5. In the Object/library modules box, insert the library names. You must make sure that these are listed in order and as the first two libraries in the line (for example, Nafxcwd.lib Libcmtd.lib).

The above settings are not identical with the menu in IVF. I can find process 4 in

Configuration Properties -> Linker -> Input -> Ignore Specific Library: LIBCMT.lib

ButI do not know how to do it for process 5. After recompiling, I got new error message:

Description File
error LNK2019:unresolved extenal symbol _iob referenced in function
for __issue_diagnostic libifcoremt.lib
error LNK2001: unresolved extenal symbol _iob libifcoremt.lib
error LNK2001: unresolved extenal symbol _iob libmmt.lib
error LNK2019: unresolved extenal symbol __argv referenced in function for _rtl_init_ libifcoremt.lib
error LNK2019: unresolved extenal symbol __argc referenced in function for _rtl_init_libifcoremt.lib

Any clue on thesestuff? Thanks!

[mecej4]

Intel provides downloads of redistributables for installation on your client's machines that do not have Intel Fortran installed. For example, the current version for Windows-X64 is

File w_cprof_p_11.1.065_redist_intel64.exe

[turkeydodo]

Thanksalot!