Question
I use a 3rd party .lib file in my project. While our project builds well and seems to work well, I get this warning from the linker:
https://stackoverflow.com/questions/18429849
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianLINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
My project is a .dll that uses Multi-threaded DLL Runtime Library (/MD option). We don't have a different version of the .lib file we can link.
Solution 2
If it builds correctly, you're fine.
The danger is that libcmt defines some functions that are also defined by the other library you're using. In this case, you'll get errors (at link time) saying a symbol is multiply defined. If it builds without errors, though, the resulting executable should be fine.
OTHER TIPS
"LIBCMT" is Microsoft's multi-threaded C runtime library. Microsoft's compiler adds information into the object files that it creates so that the linker will know which version of the runtime library the compiler thought you wanted to link with. This warning means that the information in two or more object files points to different versions of the runtime library. That's a problem, and the advice that the warning gives you to turn off the DEFAULTLIB options is really bad. Instead, figure out where the conflict is coming from and fix it. I haven't used MS's tools in several years, so I can't give you details of which tool does what, but there is a tool that dumps out information from object files (maybe objdump?), and with the right options that will give you the library information that's embedded in each object file. That, in turn, points you to the object file that's causing the problem. Then you have to figure out why it thinks it needs that version; that's usually the result of the compiler options that were used when it was compiled. So, for example, if one object file was built as multi-threaded and another was build as single-threaded, you'll get a conflict like this. You can't ignore it; if the application uses multiple threads and the linker pulled in the single-threaded library instead of the multi-threaded library, you'll get mysterious crashes in functions that aren't properly synchronized.
