C 运行时库版本兼容性：更新需要重建？
如何构建一个库（静态库或 dll/so），使其对系统 C 运行时库的未来更新不敏感？
7 月底，微软更新了一堆库，包括 C 运行时库。我们的应用程序是用 MFC/C++/VB 和一些第三方库（包括一些闭源库）混合编写的。
我一直忙于重新编译我们拥有源代码的所有库，但我想知道这是否真的有必要？如果我们链接或加载针对早期版本的 C 运行时构建的库，会发生什么？
重新编译这些东西时，主应用程序和支持库之间的哪些编译器和链接器设置必须相同？我发现运行时库设置需要相同（我们使用多线程版本/MD和/MDd），但我担心其他设置。实际上，我已将所有设置提取到 Visual Studio 属性表中，并且我对所有不同的项目使用相同的表，但这不适用于第 3 方库，我认为这有点矫枉过正。
我注意到链接器会发出 警告< /a> 关于冲突的库，但它建议忽略默认库。这样做安全吗？这似乎是一个非常丑陋的问题解决方案。
How do you construct a library (static lib or a dll/so) so that it isn't sensitive to future updates to the system's C runtime librarires?
At the end of July, Microsoft updated a bunch of libraries, including the C runtime libraries. Our app is written with a mix of MFC/C++/VB and some third party libraries, including some that are closed source.
I've been busy recompiling all of the libraries we have source to, but I am wondering if it is really necessary? What will happen if we link in or load a library built against an earlier version of the C runtime?
When recompiling this stuff, what compiler and linker settings must be the same between the main application and the supporting libraries? I've discovered that the runtime library setting needs to be the same (we use the multi-threaded version /MD and /MDd) but I'm worried about other settings. I've actually pulled all the settings out into Visual Studio property sheets and I'm using the same sheets for all our different projects, but this doesn't work for 3rd party libraries and I'm thinking it is overkill.
I have noticed that the linker will spit out a warning about conflicting libraries, but it suggests to just ignore the default libraries. Is it safe to do so? It seems like a very ugly solution to the problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您将第 3 方库作为 DLL 加载，则它们可能依赖于与可执行文件不同的运行时版本，只要
，因此，您不必重新编译 DLL。
如果你是静态的
链接到库或者如果您要移交运行时 DLL 中定义的类型，您可能会遇到一些符号问题，这些符号已经导入到您的库中，因此很可能您必须重新编译它。
If you are loading the 3rd party libraries as DLLs, they may depend on different runtime versions than your executable as long as
So, you don't have to recompile the DLLs.
If you are statically
linking to the libs or if you are handing over types defined in the runtime DLLs, you may get some problems with symbols, that are already imported in your lib, so most likely you will have to recompile it.
如果您或您的第三方组件静态链接过时的 C 库，那没问题；升级这些库不会影响您的程序。当然，您不会从任何错误修复或性能升级或您拥有的东西中受益。如果您确实重新编译代码以利用新设置，则所有运行时开关必须相同。无论何时或为何编译库，情况总是如此。忽略默认库可能是安全的（多年来我一直这样做，没有任何困难）。
动态链接库是另一个故事。如果您依赖的目标系统具有给定 dll 的特定版本，而它却具有其他不兼容的版本，那么您就完蛋了。此问题的传统解决方案是将所需的所有 dll 与可执行文件捆绑在一起。微软新推出的并行组装功能或许也能有所帮助，但它的设置总是有点太难了，我无法费心去处理它。你可能会有更好的运气。
If you or your third-party components are statically linking against out-of-date C libraries, you are fine; upgrades to those libraries will not affect your program. Of course, you won't benefit from any bug fixes or performance upgrades or what-have-you either. If you do recompile your code to take advantage of your new settings, all runtime switches must be the same. This is always the case, regardless of when or why your libraries are compiled. It is probably safe to ignore the default libraries (I've been doing so for years without difficulty).
Dynamically-linked libraries are another story. If you rely on the target system having a particular version of a given dll, and it has some other incompatible version instead, then you are screwed. The traditional solution to this problem is to bundle all the dlls you need with your executable. Microsoft's new side-by-side assembly thing might also be able to help, but it's always been a little too hard to set up for me to bother with it. You might have better luck.