Problem while calling a Fortran subroutine with C++

[jesusp68]

Hi,

I am calling a Fortran subroutine from C++. I have a small example of a simple Fortran code which includes the most common Fortran features (DO loops, IF statements,...) which compiles correctly as a .lib, which subsequentlt compiles correctly with C++ and run smoothly, ie C++ calls the Fortran code correctly and the Fortran code calculations are profromed correctly and the results are delivered to the C++ code correctly for other calculations.

I need to compile other a .lib file coming for a Fortran code which I do not have access to, with a C++ code to be called by this one. The Fortran code have been compiled and tested stand-alone and calculates correctly. I have the C++ code calling the new Fortran subroutine of the .lib file and I know the call arguments are correct and match the arguments of my call in C++. When I compile the C++ code and the fortran code .lib following the same procedure as in my working example, it gives the following errors:

**********

Deleting intermediate files and output files for project 'JesusP', configuration 'Release|Win32'.

Compiling...

ExampleUAM.cpp

ExampleModel.cpp

ExampleModel.cpp(1162) : warning C4244: 'initializing' : conversion from 'double' to 'const int', possible loss of data Compiling resources...

Linking...

LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_z already defined in MSVCRT.lib(cinitexe.obj)

LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_a already defined in MSVCRT.lib(cinitexe.obj)

LIBCMT.lib(crt0init.obj) : error LNK2005: ___xi_z already defined in MSVCRT.lib(cinitexe.obj)

LIBCMT.lib(crt0init.obj) : error LNK2005: ___xi_a already defined in MSVCRT.lib(cinitexe.obj)

LIBCMT.lib(winxfltr.obj) : error LNK2005: ___CppXcptFilter already defined in MSVCRT.lib(MSVCR71.dll)

LIBCMT.lib(crt0init.obj) : warning LNK4006: ___xc_z already defined in MSVCRT.lib(cinitexe.obj); second definition ignored

LIBCMT.lib(crt0init.obj) : warning LNK4006: ___xc_a already defined in MSVCRT.lib(cinitexe.obj); second definition ignored

LIBCMT.lib(crt0init.obj) : warning LNK4006: ___xi_z already defined in MSVCRT.lib(cinitexe.obj); second definition ignored

LIBCMT.lib(crt0init.obj) : warning LNK4006: ___xi_a already defined in MSVCRT.lib(cinitexe.obj); second definition ignored

LIBCMT.lib(winxfltr.obj) : warning LNK4006: ___CppXcptFilter already defined in MSVCRT.lib(MSVCR71.dll); second definition ignored

Creating library .\\Release/ExampleUAM.lib and object .\\Release/ExampleUAM.exp LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library

libifcoremt.lib(for_main.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main .\\Release/ExampleUAM.dll : fatal error LNK1120: 1 unresolved externals

Build log was saved at "file://c:\\Simsci\\Dss45\\Dss45\\ExampleUAM\\Release\\BuildLog.htm"

JesusP - 7 error(s), 8 warning(s)

---------------------- Done ----------------------

Rebuild All: 0 succeeded, 1 failed, 0 skipped

***********************************************************

The C++ and Fortran Visual Studio settings are exactly the same as for my working example.

No of the .lib and variables quoted in the error messages exist in any of the C++ or Fortran code. I have not access to the Fortran code.

which do you think may be the causes of the errors, in particular the Linker 2005 error?. Any recommendations?

I am using Visual Studio .NET 2003 and Intel Fortran 10.1.

Thank you very much for your help in advance.

Regards

Jesusp

[Wendy_Doerner__Intel]

The errors look the same as on this thread that Steve helped you to diagnose last month. Do you think the cause is the same? If not can you post the full Build Log.

------

Wendy

Attaching or including files in a post

[jesusp68]

Wendy,

Thanks for your response. Yes, it is the same type of error. However, the cause is different. In the original thread the cause was to have compiled as Debug. Once I compiled both the Fortran subroutine and the C++ with the fortran .lib in release mode, it worked fine. The settings were already fine. Now the problem in different. My Fortran model example (the one resolved in the prtevious thread mentioned above) works correctly. Now I have received a Fortran code which I have not access to due to confidentiality. This Fortran code has the correct statements to be connected with the C++ code as my example (I provide my example for illustration to the Fortran code developers amd compilers). I am sure that the new Fortran code have been compiled with the correct settings since I have also provided my example visual project for illustration. The model developers have also tried to replace my example code by their new code and compile so that they make sure that the compiler settings are the same. The errors obtained are the same.

I am thinking at the moment that the cause may be some instructions or some variable types of the new Fortran code, which are not compatible with the C++ compiler. I am not sure if this can be possible. What do you think?. My simple example uses limited number of different instructions such as DO, DO WHILE, IF,... The developers say that they use COMMON extensivelly. They also use EXTERNAL since they use other SUBROUTINEs which are in the same Fortran code. They use WRITE(6,*) and (*,*),... I am building an exmple usingf this type of structures to see if I can ascertain one that cause this type of problem during compilation. What do you think of this strategy?. Can you think of any possible causes for these problem different from the causes identified in the first threath?

I copied the whole Build log in my previous message.

Thanks again for your support

Regards

Jesus

[Steven_L_Intel1]

The problem here is that the C++ and Fortran projects are being compiled with different settings for the form of the run-time library. MSVC defaults to DLL libraries and Intel Fortran defaults to static libraries. These must match or else you will get this type of error from the linker.

The easiest solution is to change the Fortran project propert Libraries > Use Runtime Library to "Multithreaded DLL" in the Release configuration. In the Debug configuration you would want "Debug Multithreaded DLL". An alternative is to change the library type in the C++ project (under "Code Generation") to match the Fortran setting.

[Wendy_Doerner__Intel]

I think Steve has gotten to the source of the problem. Looking forward to hearing if that works for you.

------

Wendy

Attaching or including files in a post

[jesusp68]

Steve, Wendy,

We have debugged the issue in the following way: As explained yesterday, we replaced the example Fortran code that was compiling correctly by the confidential Fortran code in the .f90 file so that we make sure that the Intel Fortran settings are the correct ones. In this case, the compilation of theconfidential Fortran code.lib with the C++ code still gave the errors reported (while the original example did not give these errors). Then, we disabled all the Fortran code except a minimum part and it compiled without errors. When we say compile, we refer to the compilation of the Fortran code to a .lib and then the compilation of the .lib with the C++ code). Then, we have enabled the code little by little and compiling (first the Fortran to .lib and then the -lib with the C++) until we have found the statements causing the trouble. The problem was caused by a STOP statement in a SUBROUTINE. Once this STOP instruction have been removed, the code compiled correctly in the C++.

We have also observed that implementing WRITE instructions in the Fortran code to extract results into a text file / DOS window produce the same type of errors.

Is it any way of allowing a Fortran code compiled as a .lib and then compiled/called with/from a C++ code to write directly into a text file / DOS display/... ?. We do not want to go through the Subroutine arguments to wirte on an output channel if possible. This is for debugging pruproses.

Regards

Jesus

Thanks for your kind support.

Regards

Jesus

[Steven_L_Intel1]

What you have done is remove all Fortran statements that create a call to the Fortran run-time libraries. Once you do that, then you'll stop getting errors related to having inconsistent library types. You are approaching this problem from the wrong end - you have to make sure the library types are consistent between C++ and Fortran. Once you do that, you'll stop getting the errors.