ERROR LNK2005

[jvandeven]

There appears to be a conflict between the "Multithread DLL" and "Matrix Multiply" libraries, resulting in LNK2005 errors. The problem is resolved if the Matrix Multiply library is used with the "Multithreaded" library. Is there another solution (as I would like to use the Matrix Multiply optimisations in a dynamically linked application)?

Justin.

[Steven_L_Intel1]

I don't quite understand the problem you are describing. It would help if you did this - in the project properties, go to Linker > General. Set "Show Progress" to "Show all progress messages". Rebuild the application and attach (not paste) the buildlog.htm to a reply here.

I thought you might be referring to libmatmul.lib, but it does not reference any specific set of libraries.

[jvandeven]

After doing some more testing, I have found that the problem that I describe is platform specific - find attached two build logs, one where the problem exists and another where it does not. Many thanks.

[Mark_Lewy]

I wonder whether this is related to this thread?

http://software.intel.com/en-us/forums/showthread.php?t=80926

I'm having similar issues with Fortran Composer XE 2011 Update 4 (w_fcompxe_2011.4.196) and a solution that used to build in 11.1.060. Even if I ignore libcmt.lib, I still get LNK2005 errors for a clash between libmatmul.lib and mkl_intel_c_dll.lib (for symbols _sgemm and _sgemv). I'd prefer not to disable Matrix Multiply Library Calls with /Qopt-matmul- as I suspect the matrix solver we use (MUMPS) would benefit from its use. I've attached my build log.

[TimP]

Some suggestions:

If you are linking against MKL, can you exclude libmatmul.lib and link successfully?

The opt-matmul optimization should cause Fortran MATMUL to be implemented by a call to MKL BLAS, when the parameters fit. Apparently, libmatmul has copies of gemm and gemv which duplicate MKL. If the problem still occurs with the current ifort release, and can be shown in a simple example, posting a problem report on premier.intel.com should be helpful. The URL reference given earlier indicates that such a filing was made back in February, with no indication what action may have been taken for subsequent releases.

You must take care to avoid a situation where you attempt to link against both the static and dynamic multithread libraries. If you make a .dll and intend to link static libraries, you must postpone the static library linking to the final link (don't include those in the .dll).

Among the means for distributing the .dll set required for dynamic linking of ifort libraries is to download the redistributable library matching your ifort from https://registrationcenter.intel.com

[Mark_Lewy]

Thanks for the suggestions Tim.

If I add libmatmul.lib to ignore default libraries in the general linker options then _MATMUL_MKL becomes an unresolved symbol.

I've tried to produce a simple example that reproduces this problem and have not succeeded so far, so I'll probably not submit a case for this, as I can resolve the problem by using /Qopt-matmul- and hoping that the performance hit is not significant, especially as we are migrating from 11.1.060.

Have a good weekend (it's 17:30 here in the UK, so I'm off home).

Mark.

[jvandeven]

I found my error in the end - some of the DLL files that I was linking to were using the static multithreaded libraries, and others the dynamic libraries. Once I ensure that all versions were linking to the same set of libraries the problems went away. I found the LNK2005 error message a distraction on this occassion.

[Brad_Doudican]

Hi there - I'm a complete novice at programming, a civil engineer getting a Ph.D. in composite materials. I am getting the same LNK2005 error message, and believe it to be a function of the DLL linking as you describe. How do I go through the process of determining which were using static multithreaded libraries, and which dynamic libraries? Many thanks for your input.

Build log below.

BuildLog.htm

[TimP]

If you wish to go about it from the error messages, you have to decipher the names of the .lib files and infer which are import libraries referring to a .DLL (such as libcmtd.lib) and which are static libraries.
The typical inconsistency giving rise to such a mixture of Fortran static and C++ dynamic libraries is the use of VS project defaults (/MT in ifort, /MD in C++). Make them consistent and rebuild.

[junziyang]

Thanks. Changing /MD to /MT solved my problem.