LIBCMT.lib conflicts

LIBCMT.lib conflicts

Working on my home computer, a project was building fine until suddenly, for unknown reason (probably some external procedure I added), it began to give a list of linker errors "LIBCMT.lib(invarg.obj) : error LNK2005: _[various names] already defined in LIBCMTD.lib(invarg.obj)", followed by "LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library".

Coincidentally I am developing the same project on my work computer, using exactly the same files (they are all synchronized using Dropbox), and the linker errors do not occur there--only the warning. I cannot see what is different between the two locations.

What is happening? The build logs for each computer are attached.


Downloadtext/plain buildlogs.txt3.8 KB
4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

This appears to indicate an inconsistent combination of debug and release builds.  If you would rebuild the entire project with a consistent choice the problem should go away.

Thanks Tim, you have led me to the problem. I had linked to one of my own static libraries by INCLUDING it in my project, specifying a link to Mylib \release\mylib.lib. When I removed this link and added Mylib\debug\mylib.lib the problem went away. But troublesome questions remain:

1. How can one tell from studying the build log that this is the problem? I would like to be able to interpret the clues myself.

2. How could this "suddenly" become a problem on the home computer, when I had previously been using the release version of Mylib.lib, and in fact I do so frequently on other projects with no problems?

3. How can it be a problem on my home computer but not on my work computer? Both are using exactly the same files, at least as far as I can tell. Could there be some different setting in the VS environment that is not controlled by the Myproj.vfproj file? Where could I look?

4. Does this mean that I should NEVER link to a release version of a library when I am developing a project in debug mode? That would be a huge mysterious surprise because I have been doing it for years, and I would find it hard to believe it is necessary to maintain two different versions of my library, to link with one for development work and the other for release work. That would invite a lot of versioning trouble.

I looked at your logs, and your two environments are not identical.  The source files that you are linking may be, but the projects do not seem to be the same.   I don't remember which is which now, but one is using "ifort" to do the link step, the other is using "link".  

Do you have the same version of Visual Studio on both systems?

Please note that you are getting the library conflict messages in both environments, the difference is you're getting specific named variable conflicts in one of them.

There are some clues in the build log.  First - if you see both LIBCMT and LIBCMTD the second one is the debug version.  There are several "variants" (if you will) of the Microsoft C runtime library, and it is pretty easy to mix-match them incorrectly.   If you look for the various names, such as LIBCMT, or MSVCRT, that will help you figure out that there is a conflict. 

You can use both debug and release versions of libraries, but you need to be careful.    The conflicts that you are seeing here is because there are two C runtime libraries being linked in, and that's what you'd like to avoid.

When you build your debug library, change the libraries that it links against to "Multithreaded".  By default, it will be "Multithreaded, Debug".  

   I hope this helps -



Leave a Comment

Please sign in to add a comment. Not a member? Join today