我怎样才能强制 MSVC++ 忽略静态库的 CRT 依赖性？
我不知道是否可以这样做，但我希望将 /NODEFAULTLIB 应用于静态库项目。
我有许多使用公共静态库 D.lib 的应用程序项目（A.exe、B.dll、C.dll）。 该库包含大量代码，并且还具有其他 .lib 依赖项。 其中之一是 openssl 库，它似乎是针对 CRT 的发布版本为 win32 构建的（我没有原始项目/源代码）。
到目前为止，为了避免混合 CRT 的发布/调试版本，我必须将 /NODEFAULTLIB:msvcrt.lib 链接器指令放入所有叶项目（A.exe、B.dll）中。 这可行，但我认为这不是处理该问题的理想方法。 我尝试将此属性放入D.lib项目中，但没有效果。
有没有办法强制 msvc++ 忽略来自 3rd 方库的 msvcrt.lib 依赖项？
I don't know if it's possible to do this, but I would like the /NODEFAULTLIB to be applied to a static library project.
I have many application projects (A.exe, B.dll, C.dll) that use a common static library D.lib.
This library has a lot of code and also has other .lib dependencies as well. One of them is the openssl library, which seems to have been built for win32 against the Release version of the CRT (i don't have the original project/sources).
So far, to avoid the mixing of the Release/Debug versions of CRT, I have to put the /NODEFAULTLIB:msvcrt.lib linker directive in all leaf projects (A.exe, B.dll). This works but I think it's not the ideal way of dealing with that issue.
I tried to put this property in D.lib project, but it has no effect.
Is there a way to force msvc++ to ignore the msvcrt.lib dependency from the 3rd party library?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为了防止分布式静态链接库依赖于特定的 MSVC 运行时库，您需要设置此编译器选项（在 Visual Studio 2010 中它看起来像）：
Configuration Properties -> C/C++ -> 高级 -> 省略默认库名称 = Yes (/ZI)
现在，您的用户可以从其调试版本链接到您的版本构建的静态库，而不是尝试链接到导致问题的不正确的运行时库以及链接器警告。
请注意，如果您的库实际上依赖于特定的运行时库或其行为，并且未以其他方式提供兼容的组件，则可能会导致链接错误。
To prevent your distributed static link library from depending on a specific MSVC runtime library you need to set this compiler option (in Visual Studio 2010 it looks like):
Configuration Properties -> C/C++ -> Advanced -> Omit Default Library Name = Yes (/ZI)
Now your users can link to your release built static lib from their debug build and not try to link to the incorrect runtime library causing problems, as well as linkers warnings.
Note that may cause link errors if your library actually depends on a specific runtime library or its behavior, and compatible components are not provided in some other way.
.lib 没有任何链接器设置，因为您不是链接它，而是链接到它。 .lib 只是 .obj 文件的存档，有点像未压缩的 .zip 文件 - 这就是为什么您必须将设置放在链接到它的所有项目上。
如果您使用的是 VS2005+，则可以使用属性表，这样您只需将设置放在一处，然后在所有项目中使用该属性表。
然而，OpenSSL 就是这样 - 开源，因此您应该能够获取您正在使用的版本的源代码并再次构建它（当然并将其添加到您的版本控制系统中）。 我认为 OpenSSL 可以构建为 DLL 或 LIB，这可以解决您的问题，因为 DLL 不会干扰代码的链接。
如果做不到这一点，您始终可以选择将功能分割到一个单独的 DLL 中，这样您就只在一个项目中遇到问题。
A .lib does not have any linker settings because you don't link it, you link to it. A .lib is just an archive of .obj files, sort of like an uncompressed .zip file - that's why you have to put the setting on all projects that link to it.
If you're using VS2005+ you could use property sheets so that you only have to put the setting in one place and then use that property sheet in all projects.
However, OpenSSL is just that - Open Source, so you should be able to get the source for the version you are using and build it again (and add it to your version control system of course). I thought OpenSSL could be built as a DLL or LIB, which would solve your problem as the DLL would not interfere with the linking of your code.
Failing that, you always have the option of slitting your functionality out into a separate DLL so that you only have issues with one project.
我的理解是，如果库 LIB 静态链接到 DLL 中，则 DLL 已经包含 LIB 中的所有相关代码。 因此，这种耦合无法去除。 这只是基于我对静态链接的理解，而不是实验。
My understanding is that if library LIB in linked statically into a DLL, the DLL contains already all relevant code from LIB. Therefore, this coupling cannot be removed. This is just based on my understanding of statical linking, not on experiments.