/Qx cause LNK2005 libcmt.lib clash with libmmt.lib

[Samuel_D_]

Hello all,

When I turn intel-processor specific optimization in release builds I get the following linker errors :

LIBCMT.lib(pow.obj) : error LNK2005: _pow already defined in libmmt.lib(pow_stub.obj)
LIBCMT.lib(pow.obj) : error LNK2005: __CIpow already defined in libmmt.lib(pow_msci.obj)

Using

MSVS 2012 - Update 2
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 13.1.1.171 Build 20130313

The compiler options are :

/nologo /O2 /QxHost /Qipo /fpp /DNDEBUG /Qopenmp /module:"Release\\" /object:"Release\\" /Fd"Release\vc110.pdb" /libs:static /threads /c

and the linker options are :

/OUT:"Release\cli.exe" /INCREMENTAL:NO /NOLOGO uiAccess='false'" /SUBSYSTEM:CONSOLE netcdf.lib netcdff.lib hdf5.lib hdf5_hl.lib szip.lib zlib.lib proj4.lib

Nothing fancy here... Note that :

• I do not get this problem with MSVS 2010.
• The issue is x86 specific (x64 links fine)

Any ideas ?
Regards, Samuel

[TimP]

Do you still have some objects built with VS2010 which request the other library from VS2012?

Maybe hdf5 or netcdf was built with different options or compiler.  If this is intentional, you can set nodefaultlib to accept it.

similar case you should find by search engine:

http://software.intel.com/en-us/forums/topic/278038

[Samuel_D_]

Hello Tim,

> Do you still have some objects built with VS2010 which request the other library from VS2012?

No, all dependencies were rebuilt with MSVC 2012 and were build with the same options (and link to the same static runtime, I'm very carrefull about that). /nodefaultlib, suggested in the other post, obviously gives a me a bunch of unresolved external symbols.

Further questions : 

• Does /Qx automatically requires linking libmmt.lib ?
• libmmt.lib is part of Intel runtime ?
• Could it be a problem with the order of libraries when linking ?

Yet I can not explain the difference of behaviour in x86 and x64 build configurations.

[TimP]

Yes, libmmt.lib should appear in your Intel compiler installation, while libcmt.lib should appear in the Microsoft C++ installation.

Adding /# option to ifort link invocation command should show the order of searching libraries.  I would expect it should search the Intel compiler libraries before the Microsoft ones.

Remember that if you have a combined C++ and Fortran project you must set the C++ project to /MT or the Fortran to /MD, so that both are the same (static or dynamic linked).

[SergeyKostrov]

>>Further questions : >> >>- Does /Qx automatically requires linking libmmt.lib ? No. >>- libmmt.lib is part of Intel runtime ? libmmt.lib - Intel's library libcmt.lib - Microsoft's library >>- Could it be a problem with the order of libraries when linking ? No and order of the linking of some libraries is not important. For example, '...A.lib B.lib C.lib...' = '...C.lib B.lib A.lib...', and all references will be resolved anyway.

[TimP]

Sergey Kostrov wrote:

>>- Could it be a problem with the order of libraries when linking ?

No and order of the linking of some libraries is not important. For example, '...A.lib B.lib C.lib...' = '...C.lib B.lib A.lib...', and all references will be resolved anyway.

Sergey is correct, the Visual Studio linker used by ifort is not dependent on order in which libraries are presented, in contrast to open source linkers used with gfortran on Windows and all compilers on linux.  In the latter cases, you must avoid static linking if you want such freedom.

In order to avoid presenting an exception on Windows, Intel compilers have discontinued support for static linking of OpenMP (and Cilk(tm) Plus) run-time libraries, so those libraries aren't affected by /MT switch.