对于基于Linux和Windows构建的跨平台软件项目，我们有不同的方法来处理第三方库。在Linux上，我们构建和链接与CentOS / RHEL发行版分发的版本，这意味着我们链接发布版本，而在Windows上我们维护自己的第三方库“包”，在Windows上我们构建每个库的两个版本 - 链接msvcr100和msvcp100的发行版本以及链接msvcr100d和msvcp100d的调试版本。
我的问题是，是否有必要在Windows上构建第三方依赖项的调试版本，或者我们可以在构建自己的软件的调试版本时使用/ nodefaultlib：msvcr100。
后续问题：我在哪里可以了解这方面的良好做法。我已经阅读了有关msvc运行时的MSDN页面，但在推荐方面几乎没有。
编辑：
让我更简洁地重述一下这个问题。使用VS2010时，使用/ nodefaultlib：msvcr100在链接使用/ MD编译的库时链接可执行构建与/ MDd有什么问题。
我的动机是避免必须构建我使用的第三方库的发行版和调试版。此外，我希望我的调试版本运行得更快。
来自/ MD，/ MT，/ LD（使用运行时库）的文档：
MD：使您的应用程序使用运行时库的多线程和DLL特定版本。定义_MT和_DLL并使编译器将库名MSVCRT.lib放入.obj文件中。
使用此选项编译的应用程序静态链接到MSVCRT.lib。该库提供了一层代码，允许链接器解析外部引用。实际工作代码包含在MSVCR100.DLL中，它必须在运行时可用于与MSVCRT.lib链接的应用程序
/ MDd：定义_DEBUG，_MT和_DLL，并使您的应用程序使用运行时库的调试多线程和DLL特定版本。它还会使编译器将库名MSVCRTD.lib放入.obj文件中。
因此，除了定义的_DEBUG之外，没有任何文档可以对生成的代码进行任何差异。
答案 0 :(得分：3)
您只能使用CRT的Debug版本来调试您的应用。它包含许多断言以帮助您捕获代码中的错误。您从不发布项目的调试版本，始终是Release版本。你也不能，许可证禁止发送msvcr100d.dll。因此，正确构建项目可以避免依赖于CRT的调试版本。
/ nodefaultlib链接器选项意图以允许将程序与自定义CRT实现链接。非常罕见，但是一些程序员非常关心构建小程序，标准CRT并不是很小。
有些程序员使用/ nodefaultlib来解决链接问题。当它们使用调试配置设置构建的代码与使用发布配置设置构建的代码链接时引发。或链接具有不兼容的CRT选项的代码，/ MD vs / MT。这可以起作用，但不能保证，但当然只能解决地垫下的真正问题。
所以不，这不是正确的选择，修复核心问题应该是你的目标。确保使用相同的编译器选项构建所有.obj和.lib文件，并且不会出现此问题。如果这意味着你必须纠缠一个库所有者进行正确的构建，那么先破解它，只有当你发现你不想再依赖于.lib但是还没有是时候寻找替代方案了。