Can you use Intel Fortran and MS C/C++ together?

[Phil_S_]

Found this surprisely hard to get an answer for. I already have MS Visual studio for C/C++/C# programming. I recently purchased Intel fortran and it installed happily into this environment. I have a tiny piece of C that I use with the Fortran to provide SEH. Adding it the project didnt get it compiled. Do I have purchase Intel C/C++ to be able to combine fortran and C together or is there a way to use an object file from the MS compiler instead?

[Steven_L_Intel1 · Accepted solution]

Yes, you can use MS C. But MS doesn't allow mixed-language projects. So the way you have to do this is create a Visual C static library project, add your C code to it, then use Project Dependencies to make the C project a dependent of the Fortran project. The details of how you do this vary a bit by VS version.

When you build the solution, the C code will be built by MSVC, the Fortran by Intel Fortran, and then the two linked together. You can check out the examples provided in MixedLanguage.zip for worked examples.

You will also want to look at How do I configure Microsoft Visual C++ for developing mixed Fortran-C applications? should you want to use a C main program in the future.

[Phil_S_]

okay, I have been able to call the C alright. However this is fortran calling C, which then calls Fortran again. So far attempting to link I get error that the fortran routines are not found. I looked at the link on configuring VC++ for fixed fortran-C applications, and added the library directories

$(IFORT_COMPILER14)compiler\lib\ia32;$(LibraryPath)

At the moment, the routines it wants to call are in the main.for, not in library. I had this working in the automatically converted compaq sln, but not in hand built one. I tried moving those two routines to a library but no go.

The C is extremely simple:

extern int __stdcall DO_AUDIT () ;
extern int __stdcall DO_OUT () ;

int code_wrapper(int callfunc)

{
  int istat;

__try
    {
    __try
        {
            /*
            ** Call the Fortran protected code...
            */
            if (callfunc==1) {
               istat = DO_AUDIT ();
            } else {
               istat = DO_OUT ();
            }
            return istat;
        }
    __except (1 )
        {
            return 1;
                ;
        }
    }
  __finally
    {
    }
}

The fortran that it calls is:

      INTEGER FUNCTION DO_AUDIT
      use,intrinsic :: ISO_C_BINDING

     INTEGER FUNCTION DO_OUT
      use,intrinsic :: ISO_C_BINDING

Main and all libraries (C and Fortran) are compiled Debug Multithreaded (/libs:static /threads /dbglibs)

I have tried putting the library directory under Additional Library Directories and adding the fortran library with the routines as a depending of C static library. What else?

Fortran main project link line is:

/OUT:"Debug\EXERGY.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"H:\ETP\EXWIN\EXERGY\Debug\EXERGY.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"H:\ETP\EXWIN\EXERGY\Debug\EXERGY.pdb" /SUBSYSTEM:CONSOLE /IMPLIB:"H:\ETP\EXWIN\EXERGY\Debug\EXERGY.lib"

The C static library compile line is:

/ZI /nologo /W3 /WX- /Od /Oy- /D "WIN32" /D "_DEBUG" /D "_LIB" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /MTd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fp"Debug\CWRAP.pch" /Fa"Debug\" /Fo"Debug\" /Fd"Debug\vc100.pdb" /Gd /analyze- /errorReport:queue

Compile line for the fortran static library that includes the routines called by the C is:

/nologo /debug:full /Od /I"H:\ETP\exergy\hefei" /I"H:\ETP\exergy" /warn:declarations /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /c

Any help appreciated.

[Steven_L_Intel1]

You have not shown us the critical information - the error messages - but I have a likely guess. Take out the __stdcall. That is not for use with Intel Fortran (unless you've enabled CVF-compatibility). The library settings are not relevant here.

[IanH]

Are your Fortran functions and interfaces defined using the BIND(C) suffix?  If not, add it.  You should also specify the binding label using the NAME= specified in that suffix.

The use of the ISO_C_BINDING module, on its own, doesn't change anything.

[Phil_S_]

well the error is LNK2019, unresolved external symbol _DO_AUDIT&0 referenced in function _code_wrapper. However I will look at these other issues and see whether this helps. Thanks very much,

[Steven_L_Intel1]

That's probably @0 on the end. The cause is the use of __stdcall - remove it.

[Phil_S_]

Right! That did fix it. So I have main project in the solution successfully built having recreated from scratch inside VS2010 rather than converting.

BUT - back to:

2>THR.lib(thr_enthalpy.obj) : warning LNK4099: PDB 'vc100.pdb' was not found with 'THR.lib(thr_enthalpy.obj)' or at 'H:\ETP\EXWIN\EXERGY\Debug\vc100.pdb'; linking object as if no debug info
2>THR.lib(thr_vgas.obj) : warning LNK4099: PDB 'vc100.pdb' was not found with 'THR.lib(thr_vgas.obj)' or at 'H:\ETP\EXWIN\EXERGY\Debug\vc100.pdb'; linking object as if no debug info
2>THR.lib(thr_huair.obj) : warning LNK4099: PDB 'vc100.pdb' was not found with 'THR.lib(thr_huair.obj)' or at 'H:\ETP\EXWIN\EXERGY\Debug\vc100.pdb'; linking object as if no debug info
2>THR.lib(thr_bgas.obj) : warning LNK4099: PDB 'vc100.pdb' was not found with 'THR.lib(thr_bgas.obj)' or at 'H:\ETP\EXWIN\EXERGY\Debug\vc100.pdb'; linking object as if no debug info

etc etc. On a smaller project, I had fixed that by building from scratch and eliminated these but the smaller one didnt involve the c code.

In the log, I get quite a lot of messages like this:

1>error code 23 (returned by OpenValidateX) opening pdb Debug\vc100.pdb

I also now have the internal compiler error back, when I do a rebuild.

2>0_0
2>catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
2>compilation aborted for H:\ETP\exergy\thr_entropy.for (code 1)

If I a build after the rebuild, then all is well.

[Phil_S_]

The project that built earlier http://software.intel.com/comment/1779731#comment-1779731 without the any pdb problems, is now giving the same error! Only change that I can think of was changing libraries from /libs:dll to /libs:static.

[Steven_L_Intel1]

The PDB error issue seems to be a bug in Visual Studio where it keeps the file open when it shouldn't. Typically, exiting and restarting VS takes care of it.

The internal compiler error concerns me. Is this something you can reliably reproduce? Which compiler version are you using?

[TimP]

I have provoked that .pdb issue myself by having multiple builds running by mistake in the same folder.

[Phil_S_]

Restarting VS has no effect - still get vc100.pdb not found errors. The internal compiler error messages happen every time a project or solution is rebuilt (and disappear with a build), but the number of times it is reported is 3 or 4 and it is reported on different files with each rebuild, even you execute the rebuilds consecutively. The compiler verison Composer XE 2013 SP1 2.176, embedded in MS VS 2010 10.0.40219.1 SP1Rel
 

[Steven_L_Intel1]

Would you be willing to provide us with a ZIP of your project and sources? You can attach it here, or use Intel Premier Support.

[Phil_S_]

The code is fairly sensitive so not prepared to post it here. I havent used Premier Support before so let me investigate this..
 

[Phil_S_]

Okay, while preparing the solution and source code to send via Intel Premier, I cracked it. The problem was that solution was sitting living on a network drive. When I copied it to local hard drive, the problems (internal compiler error and link PDB errors) all vanished. I have working multilanguage solution that I can debug. One of those memory block problems. We have to run C++,C# projects on local drive and sync back for backup, but so used to having the fortran on the network drive I had forgotten that VS hates network drive. Thanks very much to everyone who tried to help.