Linker Conflict libmmt and libcpmtd

[acar]

Hello,

I recently migrated to the latest VS and Intel fortran compiler.  I am getting the following errors:

Severity    Code    Description    Project    File    Line    Suppression State
Error        error LNK2005: _powf already defined in libmmt.lib(powf_iface_c99.obj)        libcpmtd.lib(locale.obj)        

Any advice on overcoming this would be greatly appreciated.

Many thanks,

ACAR

[Steve_Lionel]

You are linking lots of libraries, at least some of which you did not build (and are C++). With C/C++, unlike Fortran, you can't just switch run-time library choices at link time. EVERYTHING needs to be built with the same libraries type, and /MTd is probably the least likely to be appropriate with external libraries.

It also appears that you are linking in code compiled with /Qipo that was compiled with different Intel compiler versions. You need to make sure that the same version is used across Fortran and C/C++.

[acar]

Thanks Steve.

As noted I managed to get my solution built when I excluded the clp_c_interface project so it seems that it is only this project which is causing problems.  It requires two libraries as specified earlier and I have rebuilt these using the same run-time library.  Also neither libClp.lib nor libCoinUtils.lib requires other libraries as far as I can see:

/OUT:"C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\Clp\MSVisualStudio\v14\Debug\libClp.lib" /NODEFAULTLIB:"msvcrtd" /NOLOGO /NODEFAULTLIB 

/OUT:"C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\Clp\MSVisualStudio\v14\Debug\libCoinUtils.lib" /NODEFAULTLIB:"msvcrtd" /NOLOGO /NODEFAULTLIB 

This does not make any sense to me and any further pointers would be gratefully received.

Thanks,  ACAR.

[Steve_Lionel]

libclp.lib has objects that were compiled against the non-debug C libraries (LIBCMT.LIB), but other parts of your project want the debug libraries (libcpmtd.lib) libCoinUtils.lib does not seem to request any particular libraries.

[acar]

How are you picking up this information Steve?  I can't see that libclp is linking to anything other than the compiled source code in the project directory and I am able to link this with any of the runtime libraries I choose.

[Steve_Lionel]

Searching libraries
    Searching Debug\clp_c_interface.lib:
      Found _CLP_SOLVE_LINEAR_PROGRAM
        Referenced in mp_class.obj
        Loaded clp_c_interface.lib(clp_c_interface.obj)
Processed /DEFAULTLIB:uuid.lib
Processed /DEFAULTLIB:libcpmtd
clp_c_interface.lib(clp_c_interface.obj) : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:LBR' specification
    Searching C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\Clp\MSVisualStudio\v14\debug\libclp.lib:
      Found "public: __thiscall ClpSolve::ClpSolve(void)" (??0ClpSolve@@QAE@XZ)
        Referenced in clp_c_interface.lib(clp_c_interface.obj)
        Loaded libclp.lib(ClpSolve.obj)
Processed /DEFAULTLIB:LIBCMT

Static libraries don't "link" to anything, but when you compile objects (that may go into a static library) they can contain linker directives that request the linker to search specific libraries. Here we see the linker describing what it sees as it loads various objects. It found clp_c_interface.obj which had references to uuis.lib and libcpmtd.lib, indicating it was compiled with /MTd. But then it finds ClpSolve in libclp.lib and that one has a directive for LIBCMT, the non-debug library, indicating it was compiled with /MT.

[acar]

Well this is odd because in the project properties for clp_c_interface I have set /MT.  Is there some other switch that might override this?

[acar]

Here is the command line options for the project:

/GS /TP /analyze- /W3 /Zc:wchar_t /I"C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\Clp\src" /I"C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\BuildTools\headers" /I"C:\RMA\Programs\EFE_V1.0\clp_c_interface\Clp-1.13.3\CoinUtils\src" /ZI /Gm /Od /Fd"Debug\clp_c_interface.pdb" /Zc:inline /fp:precise /D "UPPER" /D "WIN32" /D "_DEBUG" /D "_LIB" /D "_MBCS" /errorReport:none /WX- /Zc:forScope /RTC1 /Gd /Oy- /MT /Fa"Debug\" /EHsc /nologo /Fo"Debug\" /Fp"Debug\clp_c_interface.pch" 

The /MT is clearly visible yet in the buildlog it appears to have been overridden...

[Steve_Lionel]

You said earlier that you had set all the projects to use /MTd. This one doesn't. 

It's possible that it isn't clp_c_interface that is referencing libcpmtd. One thing you can do is open a Fortran command prompt window, cd to the folder with clp_c_interface.obj and type:

dumpbin -directives clp_c_interface.obj

You'll see something like:

   Linker Directives
   -----------------
   -defaultlib:ifconsol
   -defaultlib:libifcoremt
   -defaultlib:libifport
   -defaultlib:libmmt
   -defaultlib:LIBCMT
   -defaultlib:libirc
   -defaultlib:svml_dispmt
   -defaultlib:OLDNAMES

These are all the linker directives added by the compiler. (This is for a Fortran object, but you'll see other names for a C++ object.)

Another thing I have done when this is hard to figure out is to use a file search tool (I like Agent Ransack) and search the .obj and .lib files for the library name I want to avoid - libcpmtd in this case.

[acar]

Here is the output from the dumpbin command:

Microsoft (R) COFF/PE Dumper Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file clp_c_interface.obj

File Type: COFF OBJECT

   Linker Directives
   -----------------
   /DEFAULTLIB:uuid.lib
   /DEFAULTLIB:uuid.lib
   /FAILIFMISMATCH:_CRT_STDIO_ISO_WIDE_SPECIFIERS=0
   /FAILIFMISMATCH:_MSC_VER=1900
   /FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2
   /FAILIFMISMATCH:RuntimeLibrary=MTd_StaticDebug
   /DEFAULTLIB:libcpmtd
   /include:?id@?$num_put@DV?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@2V0locale@2@A
   /include:?id@?$numpunct@D@std@@2V0locale@2@A
   /DEFAULTLIB:LIBCMT
   /DEFAULTLIB:OLDNAMES
   /EDITANDCONTINUE

  Summary

           8 .CRT$XCU
          28 .bss
           8 .data
         250 .data$r
       2E188 .debug$S
          60 .debug$T
         1C0 .drectve
         E13 .rdata
         511 .rdata$r
           4 .rtc$IMZ
           4 .rtc$TMZ
          E0 .sxdata
          7C .text$di
        C274 .text$mn
         9B1 .text$x
          3C .text$yd
         CDC .xdata$x

It appears to be using both libcpmtd and libcmt as runtime libraries?

[Steve_Lionel]

libcmt is the C run-time library, libcpmtd is the (Debug) C++ run-time library. I'm not sure how the C++ compiler would choose to reference both of those together, but I am not a C/C++ expert. It isn't a Fortran issue. https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx describes the various MSVC libraries.

[andrew_4619]

Just a thought ( I have no special knowledge wrt this problem) the compiler directives for the libraries can come from directives embedded in the source file (clp_c_interface.c) as well as the compile options. It is worth checking both options. 

[acar]

I have changed the runtime library to MTd in the properties dialog for the project.  This results in:

Microsoft (R) COFF/PE Dumper Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file clp_c_interface.obj

File Type: COFF OBJECT

   Linker Directives
   -----------------
   /DEFAULTLIB:uuid.lib
   /DEFAULTLIB:uuid.lib
   /FAILIFMISMATCH:_CRT_STDIO_ISO_WIDE_SPECIFIERS=0
   /FAILIFMISMATCH:_MSC_VER=1900
   /FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2
   /FAILIFMISMATCH:RuntimeLibrary=MTd_StaticDebug
   /DEFAULTLIB:libcpmtd
   /include:?id@?$num_put@DV?$ostreambuf_iterator@DU?$char_traits@D@std@@@std@@@std@@2V0locale@2@A
   /include:?id@?$numpunct@D@std@@2V0locale@2@A
   /DEFAULTLIB:LIBCMTD
   /DEFAULTLIB:OLDNAMES
   /EDITANDCONTINUE

  Summary

           8 .CRT$XCU
          28 .bss
           8 .data
         250 .data$r
       2E188 .debug$S
          60 .debug$T
         1C1 .drectve
         E13 .rdata
         511 .rdata$r
           4 .rtc$IMZ
           4 .rtc$TMZ
          E0 .sxdata
          7C .text$di
        C274 .text$mn
         9B1 .text$x
          3C .text$yd
         CDC .xdata$x

Thanks for your suggestion Andrew.  I have checked the source code clp_c_interface.ccp for compiler directives and can find none:

// clp_interface.cpp : Defines the entry point for the static library application.

//

#include <windows.h>

#include <stdio.h>

#include "ClpSimplex.hpp"

#define EXTERN extern "C" {

#define EXTEND }

#define INTEL_BINDING __cdecl

#ifdef UPPER

#define clp_solve_linear_program CLP_SOLVE_LINEAR_PROGRAM

#define clp_usercallback CLP_INTERFACE_MODULE_mp_CLP_INTERFACE_CALLBACK_FUNCTION

#else

#define clp_solve_linear_program clp_solve_linear_program_

#endif

EXTERN int INTEL_BINDING clp_usercallback(int *caller);

EXTEND

EXTERN int INTEL_BINDING clp_solve_linear_program(char *infile, int *opt, int *nproc, char *outfile, int len1, int len2)

{

   char *Input_Filename;

//   int   Optimiser;

//   int   Number_of_Processors;

   char *Output_Filename;

#define STRNCPY1(y,x,l) {int ic,il; \

for (il=l-1; x[il] == ' ' && il >= 0; il--) { } \

for (ic = 0; ic <= il; ic++) { \

y[ic] = x[ic]; \

} \

y[il+1] = '\0'; \

}

#define clp_output MP_CLASS_mp_CLP_OUTPUT

   extern void clp_output(double*,double*);

   Input_Filename = (char *) malloc( (len1+1) * sizeof(char));

   STRNCPY1(Input_Filename, infile, len1);

   Output_Filename = (char *) malloc( (len2+1) * sizeof(char));

   STRNCPY1(Output_Filename, outfile, len2);

   ClpSimplex  model;

   int status;

   status=model.readMps(Input_Filename,true);

   if(status=0);

  {

 ClpSolve solvectl;

 solvectl.setSolveType(ClpSolve::useBarrier);

 solvectl.setPresolveType(ClpSolve::presolveOff);

 model.initialSolve(solvectl);

 //double * columnPrimal = model.primalColumnSolution();

 //double * rowDual = model.dualRowSolution();

 //clp_output(&columnPrimal[0:10],&rowDual[0]);

 double * columnObjective = model.objective();  

 double objective = model.objectiveValue();    

 FILE *fp=fopen(Output_Filename,"w");

 int iRow;

 int numberRows = model.numberRows();

 int iCol;

 int numberColumns = model.numberColumns();

 double value;

 double * columnPrimal = model.primalColumnSolution();

 double * rowDual = model.dualRowSolution();

 char * columnName;

 char * rowName;

 double * primalColumnSolution = model.primalColumnSolution();

 double * dualRowSolution = model.dualRowSolution();

 double * columnLower = model.columnLower();

 double * columnUpper = model.columnUpper();

 fprintf(fp,"%s\n","Primal Solution");

 for (iCol=0;iCol<numberColumns;iCol++) {

 value = primalColumnSolution[iCol];

 columnName = CoinStrdup(model.columnName(iCol).c_str());

 fprintf(fp,"%s %e\n",columnName,value);

}

 fprintf(fp,"%s\n","Dual Solution");

 for (iRow=0;iRow<numberRows;iRow++) {

 value = rowDual[iRow];

 rowName = CoinStrdup(model.rowName(iRow).c_str());

 fprintf(fp,"%s %e\n",rowName,value);

  }

 fclose(fp);

 free(Input_Filename);

 free(Output_Filename);

  }

return status;

}

}

[Steve_Lionel]

Ok, now that object shows a consistent set of libraries.

[acar]

Indeed and the logic might be to change the runtime libraries for the other projects in this solution to /MTd.  If I do this then I get another conflict as shown in the attached buildlog.

[Steve_Lionel]

In my view, unless you're going to be doing debugging of the C libraries, or relying on the debug libraries extra checking of get/free, you're better off linking to the non-debug libraries all around. That said, your new log shows:

        Loaded libclp.lib(ClpSolve.obj)
Processed /DEFAULTLIB:LIBCMT

so you still have inconsistent settings. For the Fortran library projects it might make sense to set the property "Disable OBJCOMMENT linker directives" to Yes (under Libraries). You might have to manually name the Fortran libraries under Additional Dependencies when you link.

[acar]

The c libraries are unlikely to require debugging so I can live with that.  However, I must be misunderstanding some of the suggestions I have received.  The background to this is that I was simply migrating a fully working solution from a previous version of VS and Intel Fortran.  I have understood from your advice that the runtime libraries should be consistent (identical) for the projects involved in the solution.I have done this but as we have seen /MT and /MTd leads to errors.  I cannot therefore see where I have any inconsistent settings.  Are you now suggesting that I change the runtime libraries for the c libraries to /MT whilst leaving the fortran objects as /MTd?  As always, thanks for your continued assistance.

[Steve_Lionel]

Consistent means consistent. Use all /MT (or better, all /MD). I am not aware of anything in a new version that would trigger this difference, though you started this thread with a somewhat different issue. Also, your inconsistencies seem to be all on the C/C++ side.

[mecej4]

I am gratified to see Steve L. make a direct and clear statement regarding the use of "debug libraries" in #38. In my experience, in which I have heavy exposure to character mode applications, I have never needed to use the "debug" versions of the Fortran, C/C++ or OS libraries. Consequently, I have run into the multiple library syndrome only in those instances where I had to use a third party library or DLL for which no source code was provided, and that library or DLL had a dependence on the "debug" RTLs.

As Steve said, don't use /MTd or /MDd unless you have a definite reason to do so. Likewise, if you provide a library or DLL to users, don't build it using /MTd or /MDd. Furthermore, in most situations it is preferable to use /MD instead of /MT, especially if your application uses MKL routines. I have seen some simple MKL-dependent programs generate an 80 MB EXE with /MT and just 1 MB with /MD.

[acar]

I am still struggling to understand where the problem lies.  I have a solution which I have linked with the /MTd RTLs and it works fine.  I then add my clp_c_interface.cpp which requires two libraries which I have access to the source code and have linked with the same /MTd RTLs.  I do not therefore see how there can be a conflict yet one appears.  

I have taken the suggestion to link all parts of my project against the /MD RTLs.  It again fails seemingly with conflicts between libifcoremd and libifcoremt, amongst others.  I have attached the buildlog for perusal.

If there is something I can do to get rid of this then do please advise me - thanks.

[mecej4]

Acar, here we are at response #40 in this thread, apparently stuck in a loop. It is perhaps time to re-evaluate your position regarding a reproducer (see #2). If there are concerns regarding publishing your sources, you may either prune the code to make the concerns go away before posting, or provide the code as-is to Intel personnel only. 

If you decide to share a reproducer, I suggest that you break up the sources into one Zip per library or application and attach the zips to your reply. Alternatively, you can compile the user libraries yourself (using /MD) and provide only the pre-built libraries, plus the sources for the application that is to be built with these libraries, and a few notes to guide the building process.

Sometimes, it helps to break the log jam if more than one toolset can be tried on the problem, so attempting to rebuild with an older or newer toolset is a low-cost effort way of troubleshooting.

[Added a few minutes later] I have looked at your latest BuildLog.htm. There are only two missing external symbols: CrtDbgReportW and invalid_parameter. The "debug" libraries/DLLs msvcrtd and msvcurtd provide these symbols; the non-debug libraries msvcrt and msvcurt do not. The missing symbols are referenced in your libraries libclp.lib, libCoin_utils.lib and clp_c_interface.lib. If you wish to use the "release" dynamic RTL libraries/DLLs, as is consistent with the /MD option, you probably need to rebuild these three libraries from sources using /MD. 

[Steve_Lionel]

See my earlier suggestion to use a file searching tool to search the .obj files for the conflicting library name.