redefined function call when linking Fortran and C

[tcurry]

I am using Compaq Visual Fortran 6.5 project and I added some C code to my fortran. I had to link with the winsock2.dll because I have added some C code socket calls. When I did this I started getting the following 'already defined' error messages. I tried to ignore libcmt.lib and libc.lib in my settings but I still got the same errors.

Does anyone know something I can try?

Thanks,
Tim



Linking...
nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in libcmt.lib(new.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in libcmt.lib(delete.obj)
libcmtd.lib(dbgheap.obj) : error LNK2005: _malloc already defined in libcmt.lib(malloc.obj)
libcmtd.lib(dbgheap.obj) : error LNK2005: __nh_malloc already defined in libcmt.lib(malloc.obj)
libcmtd.lib(dbgheap.obj) : error LNK2005: __heap_alloc already defined in libcmt.lib(malloc.obj)
libcmtd.lib(dbgheap.obj) : error LNK2005: _calloc already defined in libcmt.lib(calloc.obj)
libcmtd.lib(dbgheap.obj) : error LNK2005: _realloc already defined in libcmt.lib(realloc.obj)
libcmtd.lib(dbgheap.obj) : error LNK2005: _free already defined in libcmt.lib(free.obj)
libcmtd.lib(dbgheap.obj) : error LNK2005: __msize already defined in libcmt.lib(msize.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: __get_sbh_threshold already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: __set_sbh_threshold already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: ___sbh_heap_init already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: ___sbh_find_block already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: ___sbh_free_block already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_block already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_region already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: ___sbh_alloc_new_group already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: ___sbh_resize_block already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: ___sbh_heapmin already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: ___sbh_heap_check already defined in libcmt.lib(sbheap.obj)
libcmtd.lib(sbheap.obj) : error LNK2005: ___sbh_threshold already defined in libcmt.lib(sbheap.obj)
LINK : warning LNK4098: defaultlib "libcmtd.lib" conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib "libc.lib" conflicts with use of other libs; use /NODEFAULTLIB:library

[Jugoslav_Dujic]

In general, do not use "Ignore libraries" option (especially for libcXXX.lib) -- the suggestion by the linker is misleading, because it cures the symptoms rather than causes.

What you have is unoficially known as "Multiple C library syndrome" and described in this article by Steve. Briefly, instead of "ignore libraries", you should assure that settings on "C++/Code Generation/Use run-time library" and "Fortran/Libraries/Use run-time library" tabs of project settings are the same (for both Debug and Release configurations). Judging on the errors, you currently have "Multi-threaded Debug" on one and "Multi-threaded" on another.

Jugoslav

[rondavis]

Quoting - Jugoslav Dujic

In general, do not use "Ignore libraries" option (especially for libcXXX.lib) -- the suggestion by the linker is misleading, because it cures the symptoms rather than causes.

What you have is unoficially known as "Multiple C library syndrome" and described in this article by Steve. Briefly, instead of "ignore libraries", you should assure that settings on "C++/Code Generation/Use run-time library" and "Fortran/Libraries/Use run-time library" tabs of project settings are the same (for both Debug and Release configurations). Judging on the errors, you currently have "Multi-threaded Debug" on one and "Multi-threaded" on another.

Jugoslav

The link"this artice by Steve" yields the stern message

You are not authorized to view this page

and no other information. The specific remedy described here is not applicable - I do have consistent settings. I desperately need to solve this problem. Is there any way I can access the cited article?

[Steven_L_Intel1]

Please describe the problem in detail. It may not be the same as the other user. If you can, copy the contents of the build log, a link to which is given at the end of the build.

[rondavis]

Quoting - Steve Lionel (Intel)

Please describe the problem in detail. It may not be the same as the other user. If you can, copy the contents of the build log, a link to which is given at the end of the build.

Thank you, Steve, for your attention, but I seem to have stumbled into the solution to this problem.

I am working with a mixed-language program, Fortran 95 and C. I have set up two projects under the solution; one for the Fortran code and one for the C code. (The C project creates a library, but I can't use that because some of the C routines call Fortran routines in addition to the converse. I have placed references to the necessary .obj files in the Fortran project in the manner of source files; crude, but it works.)

The change that seems to make the difference is in the properties of the C project: Configuration Properties General Project Defaults Use of MFC changed to "Use MFC in a Static Library".

Thank you also to Jugoslav Dujic, whose post was not precisely applicable in my case, but gave me a good clue.

I still would like to see "this article by Steve", if the link in Jugoslav's article could be repaired or replaced.

[Steven_L_Intel1]

Here is the original article. Note that it was written for CVF so some of the details are different for Intel Fortran.

The Heartbreak of MCLS

Peter Karam
Visual Fortran Engineering

In newsletter issue VI, Lorri Menard wrote an article titled:

Do you suffer from the heartbreak of MCLS (Multiple C Library Syndrome)?

In the V6.6 release of CVF, we have made some changes to the build environment to assist with relieving the "heartbreak of MCLS". This is an enhanced version of the original article, reflecting how CVF V6.6 will assist with overcoming this malady.

We estimate that this problem affects most users the first time they build a Fortran and C/C++ mixed-language application. It affects almost every user that builds a Fortran and MFC application. It can also affect pure Fortran applications, specifically ones that use DLLs or external libraries.

Q: What is it?
A: This problem is called "Multiple C-Library Syndrome", and it's caused by trying to use more than one type of C/C++ run-time library.

Q: What are the symptoms?
A: The symptom happens at link-time. The indication that there are multiple C libraries is a warning similar to the following:

LINK : warning LNK4098: defaultlib "msvcrt.lib" conflicts with use of other libs; use /NODEFAULTLIB:library

Q: What causes Multiple C-Library Syndrome?
A: There are a number of C/C++ run-time libraries that offer the same entry points but have different characteristics. The basic C library is libc.lib, which is single threaded, non-debug, and static. Its debug counterpart is libcd.lib. The threaded version of this is libcmt.lib, and debug, libcmtd.lib. There is a multithreaded DLL version of the C run-time library msvcrt.dll, its import library is called msvcrt.lib. The debug version is msvcrtd.dll, with the import library msvcrtd.lib.

There is a similar set of Fortran run-time libraries. The basic Fortran library is dfor.lib, which is single-threaded, non-debug, and static. The threaded version of the non-debug, static library is dformt.lib. There is a single-threaded, non-debug DLL version dforrt.dll, with an import library dfordll.lib. Fortran also provides a multithreaded DLL version, dformd.dll, accessed through the import library dformd.lib.

For completeness, the DLLs dforrtd.dll and dformdd.dll and their respective import libraries, dfordlld.lib and dformdd.lib ship with CVF V6.6. These do not provide debug objects, but the DLL files are linked to use the debug version of the C DLL.

Q: Are there run-time implications?
A: Yes! Even if you don't get the outward symptoms of LNKxxxx errors, if you have multiple copies of the libraries, you've got multiple copies of data, such as errno, or Fortran I/O units.

Q: I followed the suggestion in the linker warning and built my application with /NODEFAULTLIB. Won't that solve the problem?
A: While that resolves the warning, it doesn't solve any of the underlying problems of having multiple copies of the libraries.

Q: What causes the conflict?
A: The most common source of conflict was that C/C++ provides both debug and non-debug versions of their libraries. By default, C/C++ selects the debug DLL library when the build configuration is DEBUG using DLL libraries. In CVF V6.5, and earlier, the Fortran debug build referenced the Fortran DLL that referenced the C non-debug DLL, thus causing a conflict.

CVF V6.6 eliminates this conflict. When DLL libraries are being linked against and C debug libraries are being used, the Fortran DLL library that uses the C debug DLL will now used.

The next most common source of conflict is mismatched "types" of libraries. By default, Fortran console applications and static library applications link against the static libraries, dfor.lib and libc.lib. QuickWin and Windows applications link against the multithreaded static libraries, dformt.lib and libcmt.lib. Fortran Dynamic Link Library applications link against dynamic link libraries, dfordll and msvcrt. In a similar manner, different C/C++ applications link against different C libraries. If you mix the different types of applications without modifying the defaults, you can get conflicts.

Pure Fortran applications can have mismatched "types" of libraries too. One common scenario is a QuickWin application linking against a static library. QuickWin must use the multithreaded libraries, and by default, static libraries are built using static, single-threaded libraries. This causes a conflict.

Q: How do you resolve the conflicts?
A: Start with Project-Settings. If you have a mixed-language program, compare which libraries are being linked against by Fortran with those being linked against by C/C++. Which Fortran libraries are linked against are controlled by the Use run-time library drop down list found under Project, Settings, Fortran tab, Libraries category. The drop down list has been extensively revised in CVF V6.6. Select the item which matches the selection used in the C/C++ Code Generation category. Use run-time library drop down list.

If this doesn't resolve the conflict, compare the "types" of libraries being used by the two languages. If the C/C++ (or MFC) application needs to use the threaded library, make sure that Fortran is configured to do the same.

If you have a pure Fortran application where part of the application requires threads, but part(s) were not built multithreaded, go back and rebuild those parts. There is a minimal performance cost to having an application built to be multithreaded yet run only single-threaded, but the reverse is impossible. That is, you cannot (successfully) run an application built to be single-threaded in a multithreaded manner.

Q: Is it really that easy to resolve?
A: Yes. Just take a few minutes to look at what libraries are being requested, and if there's any confusion, look at what libraries are being mentioned in the linktime messages. These two pieces of information should allow you to resolve any Multiple C-Library Syndrome conflicts. Use the simple chart below to figure out which library you are using and which you should be using.

This list identifies which libraries are selected based on the selections in the Use run-time library drop down list found under Project, Settings, Fortran tab, Libraries category. Note that the "debug" in this context refers to the -dbglibs command line option, not the -debug command option.

Single-Threaded              - dfor.lib,     libc.lib
Single-Threaded DLL          - dfordll.lib,  msvcrt.lib
Multithreaded                - dformt.lib,   libcmt.lib
Multithreaded DLL            - dformd.lib,   msvcrt.lib
Debug Single-Threaded        - dfor.lib,     libcd.lib
Debug Single-Threaded DLL    - dfordlld.lib, msvcrtd.lib
Debug Multithreaded          - dformt.lib,   libcmdt.lib
Debug Multithreaded DLL      - dformdd.lib,  msvcrtd.lib
QuickWin                     - dformt.lib,   libcmt.lib
Standard Graphics            - dformt.lib,   libcmt.lib
Debug QuickWin               - dformt.lib,   libcmtd.lib
Debug Standard Graphics      - dformt.lib,   libcmtd.lib