3

对于构建在 Linux 和 Windows 上的跨平台软件项目，我们有不同的方法来处理第三方库。在 Linux 上，我们构建并链接与 CentOS/RHEL 发行版一起分发的版本，这意味着我们链接到发布版本，而在 Windows 上，我们维护自己的第三方库“包”，在 Windows 上，我们为每个库构建两个版本 -链接 msvcr100 和 msvcp100 的发布版本和链接 msvcr100d 和 msvcp100d 的调试版本。

我的问题很简单，是否有必要在 Windows 上构建第三方依赖项的调试版本，或者我们可以在构建我们自己的软件的调试版本时简单地使用 /nodefaultlib:msvcr100。

一个后续问题：我在哪里可以了解这方面的良好做法。我已经阅读了有关 msvc 运行时的 MSDN 页面，但在建议方面几乎没有。

编辑：

让我更简洁地重新表述这个问题。在 VS2010 中，使用 /nodefaultlib:msvcr100 将可执行构建与 /MDd 链接时，与使用 /MD 编译的库链接有什么问题。

我这样做的动机是避免必须构建我使用的第三方库的发布版本和调试版本。另外我希望我的调试版本运行得更快。

从 /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 之外，没有任何文档说明对生成的代码所做的任何差异。

4

1 回答 1

3

您仅使用 CRT 的调试版本来调试您的应用程序。它包含许多断言来帮助您发现代码中的错误。您永远不会发布项目的调试版本，总是发布版本。你也不能，许可证禁止发送 msvcr100d.dll。因此，正确构建您的项目会自动避免对 CRT 调试版本的依赖。

/nodefaultlib 链接器选项旨在允许将您的程序与自定义 CRT 实现链接。很少见，但一些程序员非常关心构建小程序，标准 CRT 并不完全是小程序。

一些程序员使用 /nodefaultlib 解决了链接问题。当他们将使用调试配置设置构建的代码与使用发布配置设置构建的代码链接时引发。或具有不兼容 CRT 选项的链接代码，/MD 与 /MT。这可以工作，不能保证，但当然只能扫地垫下的真正问题。

所以不，这不是正确的选择，解决核心问题应该是你的目标。确保所有 .obj 和 .lib 文件都是使用相同的编译器选项构建的，这样就不会出现这个问题。如果这意味着您必须纠缠图书馆所有者以获得正确的构建，那么请先纠缠，只有当您发现您不想再依赖该 .lib 但还没有是时候寻找替代方案了。

于 2013-10-06T19:34:48.633 回答