Linking problems when mixing C++ with Fortran

[jlperla]

Hi there,

Sorry if this question is a repeated question, but I can't find the solution and am at a loss.

I am using Intel C++ and Fortran 11.0 on Windows. I am doing my builds through nmake (actually cmake generating nmake) and occasionally visualstudio for the C++ part.

I believe that I have compiled a fortran lib with static linking and the debug dll version of the runtime (I need MDd because I am linking between a whole bunch of libraries and that seems to be the standard). The key compiler flags for fortran are:
"/debug:full /Od /gen-interfaces /warn:interfaces /libs:dll /threads /c /dbglibs"

linker flags for fortran are:
/INCREMENTAL:YES /debug /pdbtype:sept /NODEFAULTLIB

I am linking to the following for my C++ console application:

• mkl_core
• mkl_intel_c
• mkl_intel_thread
• libiomp5md
• ifconsol.lib //Tried this, didn't help and didn't need it for a previous project.

Now I have a C++ project where I am trying to call my function. It is using the MDd runtime n C++.

However, when I link I get the error:
1>libifcoremdd.lib(for_main.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main

Any ideas? It looks to me like I should compile my static lib with something like -nofor_main function looks like a culprit, but I don't see any version for windows?

Thanks,
Jesse

[sarma_amras]

Quoting - jlperla

Hi there,

Sorry if this question is a repeated question, but I can't find the solution and am at a loss.

I am using Intel C++ and Fortran 11.0 on Windows. I am doing my builds through nmake (actually cmake generating nmake) and occasionally visualstudio for the C++ part.

I believe that I have compiled a fortran lib with static linking and the debug dll version of the runtime (I need MDd because I am linking between a whole bunch of libraries and that seems to be the standard). The key compiler flags for fortran are:
"/debug:full /Od /gen-interfaces /warn:interfaces /libs:dll /threads /c /dbglibs"

linker flags for fortran are:
/INCREMENTAL:YES /debug /pdbtype:sept /NODEFAULTLIB

I am linking to the following for my C++ console application:

• mkl_core
• mkl_intel_c
• mkl_intel_thread
• libiomp5md
• ifconsol.lib //Tried this, didn't help and didn't need it for a previous project.

Now I have a C++ project where I am trying to call my function. It is using the MDd runtime n C++.

However, when I link I get the error:
1>libifcoremdd.lib(for_main.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main

Any ideas? It looks to me like I should compile my static lib with something like -nofor_main function looks like a culprit, but I don't see any version for windows?

Thanks,
Jesse

Hi...to my knowledge you have landed up at this error because you are using the MULTITHREAD DEBUG DLL (MDd)mode to call a static library.
Try using the MULTITHREAD DLL mode (MTd) in you C++ routine though you are trying to link to the DLL's.

[jlperla]

Quoting - sarma_amras

Hi...to my knowledge you have landed up at this error because you are using the MULTITHREAD DEBUG DLL (MDd)mode to call a static library.
Try using the MULTITHREAD DLL mode (MTd) in you C++ routine though you are trying to link to the DLL's.

Thanks for your response!

Sadly, I need to use MDd in my C++ library because I am using a whole bunch of other libraries linked with that C++ runtime library. (isn't MDd the multithreaded dll runtime and MTd the non-dll version?)

Isn't it possible in mixed language to create a static library linked to the MDd runtime dll like it is in C++? I was under the impression that if I create a static library and use "/libs:dll /threads /c /dbglibs" when compiling my fortran, that it would use the equivalent to /MDd in C++?

[jlperla]

Quoting - jlperla

Thanks for your response!

Sadly, I need to use MDd in my C++ library because I am using a whole bunch of other libraries linked with that C++ runtime library. (isn't MDd the multithreaded dll runtime and MTd the non-dll version?)

Isn't it possible in mixed language to create a static library linked to the MDd runtime dll like it is in C++? I was under the impression that if I create a static library and use "/libs:dll /threads /c /dbglibs" when compiling my fortran, that it would use the equivalent to /MDd in C++?

I think I may have fixed my problem:

Add /libdir:noauto to the compiler options

Add /NODEFAULTLIB to the linker options

[jlperla]

Quoting - jlperla

I think I may have fixed my problem:

Add /libdir:noauto to the compiler options

Add /NODEFAULTLIB to the linker options

Sorry, I spoke too soon and ran into another problem I need help with.

The /libdir:noauto seems to have removed the _MAIN__ Problem,

This all worked when I just had a basic routine. But the routine I am calling now generates the following link errors:

1>etk_fortran-d.lib(solab.f90.obj) : error LNK2019: unresolved external symbol _for_check_mult_overflow referenced in function _ZSOLAB
1>etk_fortran-d.lib(solab.f90.obj) : error LNK2019: unresolved external symbol _for_alloc_allocatable referenced in function _ZSOLAB
1>etk_fortran-d.lib(solab.f90.obj) : error LNK2019: unresolved external symbol _for_write_seq_lis referenced in function _ZSOLAB
1>etk_fortran-d.lib(solab.f90.obj) : error LNK2019: unresolved external symbol _for_deallocate referenced in function _ZSOLAB

I assume that this is because it is using the fortran function ALLOCATE. I figured this function might be defined in libifcoremdd, but when I added this library in to the manual link, I got the old:

1>libifcoremdd.lib(for_main.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main

...missing symbol. But it also doesn't mention the other symbols, so I figure this might be the library that has these defined (It looks like it from looking at the symbols in the actual library file).

Any ideas?

[jlperla]

Quoting - jlperla

Sorry, I spoke too soon and ran into another problem I need help with.

The /libdir:noauto seems to have removed the _MAIN__ Problem,

This all worked when I just had a basic routine. But the routine I am calling now generates the following link errors:

1>etk_fortran-d.lib(solab.f90.obj) : error LNK2019: unresolved external symbol _for_check_mult_overflow referenced in function _ZSOLAB
1>etk_fortran-d.lib(solab.f90.obj) : error LNK2019: unresolved external symbol _for_alloc_allocatable referenced in function _ZSOLAB
1>etk_fortran-d.lib(solab.f90.obj) : error LNK2019: unresolved external symbol _for_write_seq_lis referenced in function _ZSOLAB
1>etk_fortran-d.lib(solab.f90.obj) : error LNK2019: unresolved external symbol _for_deallocate referenced in function _ZSOLAB

I assume that this is because it is using the fortran function ALLOCATE. I figured this function might be defined in libifcoremdd, but when I added this library in to the manual link, I got the old:

1>libifcoremdd.lib(for_main.obj) : error LNK2019: unresolved external symbol _MAIN__ referenced in function _main

...missing symbol. But it also doesn't mention the other symbols, so I figure this might be the library that has these defined (It looks like it from looking at the symbols in the actual library file).

Any ideas?

I am sorry to keep replying to my own post, but I wanted to keep a log in case someone else searches for this problem.

I had been trying to test a program using BOOST unit testing. I have plenty of C++ boost tests that work fine, even when linking in fortran libraries. When I finally decided to test in an executable not generated by boost unit testing, things seemed to work fine.

So, the end result is: Compiling a static fortran library with just: "/libs:dll /threads /c /dbglibs" for debug, (get rid of /dbglibs for a release build) not doing anything fancy with the fortran library linking. Then just compile the C++ library with MDd, the static lib and things work. Unless you are using boost unity testing.

[anthonyrichards]

You appear to want to create a .LIB or a .DLL. If you are getting a reference to '_main' then you may have included in your project a Fortran Program module (ora previously compiled.obj file)that you previously used to create an .EXE, which requires call to _main by the system as an entry point into the executable. A .DLL is entered with a call to _dllmain I think. A .LIB library just stores objects with a list of object names for linking purposes and makes no reference to _main or _dllmain.