2

I'm trying to link a Windows executable that depends on a several static libraries (some of which I have built, some of which I have not). When I do the link, I get a flock of errors like:

LIBCMT.lib(mlock.obj) : error LNK2005: _unlock already defined in MSVCRT.lib(MSVCR100.dll)

which is the classic /MD vs. /MT problem (whether the C runtime is statically or dynamically linked). I tried the easy solution first, adding the linker flags

/nodefaultlib:libcmt /nodefaultlib:libcpmt

but that just gave different errors:

msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: __cdecl std::_Locinfo::~_Locinfo(void)" (??1_Locinfo@std@@QEAA@XZ) already defined in gtest.lib(gtest-all.cc.obj)
gtest.lib(gtest-all.cc.obj) : error LNK2001: unresolved external symbol "private: static int std::locale::id::_Id_cnt" (?_Id_cnt@id@locale@std@@0HA)

I've gone through the libraries I'm building, and as far as I can tell I'm building them all /MD. I say "as far as I can tell" because some of them are third-party libraries that come with their own makefiles so I don't have complete control over the build process..

I don't think "depends" works on libraries (only EXEs and DLLs), is there a tool that would let me look at the various libraries I'm linking in, and see which one is bringing in libcmt when I want to be using msvcrt instead?

Betty Crokker
  • 3,001
  • 6
  • 34
  • 68
  • The premise that you can't control this with boost is just false. It even uses a different name for the .lib file, all you can do is pick the wrong name. Not for gtest, typical Google problem, you really do have to rebuild it. /MD is the universal "always works" setting, use it consistently. – Hans Passant Mar 12 '14 at 15:06
  • Sorry, mentioning boost was a bad idea. There are several third-party libraries involved, boost is only one. I am selecting what I believe to be the correct boost libraries, but (1) I might be doing it wrong, and (2) there are other third-party libraries that aren't as straight-forward. – Betty Crokker Mar 12 '14 at 18:57

1 Answers1

3

I have had the same problem and I used dumpbin ( http://msdn.microsoft.com/en-us/library/z66yd3h6.aspx ) with /DIRECTIVES options on the libs. It will show a number of /DEFAULTLIB sections, each one is another lib that your lib try to use. Dumpbin needs to run from the Visual Studio command promt.

dumpbin /DIRECTIVES liblua52.lib

I had 100+ libs with all the solution configurations and platforms so I made a python 2.7 script (crtdisplay.py) to do it for me. It can be found on my bitbucket repository at https://bitbucket.org/vimarina/ctrlcv/src/57b7ddca15b5c7fefddcf20ffcea0633223a4bd6/crtdisplay . Put it in the root directory of your libs. Not much error checking in that code so do not be surprised if it fails :). I used Visual Studio 2010 so might fail on other versions of Visual Studio. 

 crtdisplay.py > info.txt
Vim
  • 46
  • 2
  • I had trouble just scouting around using dumpbin, as /DIRECTIVES didn't show anything interesting. It turns out that some of the libs didn't have any at all. Those are not the problem! Scanning through all the libs until I found some with directives listed and eventually found conflicting ones. – JDługosz Feb 10 '16 at 10:40