考虑这种情况：应用程序链接到第 3 方库 A。
A 是使用 MSVC 2008 构建的，并且静态链接（即使用 /MT 构建）到 C 运行时库 v9.0。
该应用程序是使用 MSVC 2005 构建的，并且静态链接到 A 和（使用 /MT）到 C 运行时库 v8.0。
我可以看到这个问题 - 例如，如果运行时库版本之间的标头中的类型发生了变化。
是否注意保持运行时库标头在版本之间兼容，或者是否应该始终确保所有静态链接的库都链接到相同版本的运行时库？
问问题
2880 次
3 回答
14
这应该不是问题。每个库都链接到自己的运行时，并且大部分功能独立于进程中的其他库。当库 ABI 定义不正确时，就会出现问题。如果在一个库中分配任何类型的堆分配对象，通过库边界并在另一个库中“释放”，则会出现问题，因为正在使用不同的堆管理器从用于分配的堆管理器中释放块它。
任何类型的 c-runtime 定义的结构、对象或实体都不应跨越可能使用不同运行时版本的边界传递：- 例如，从一个库获得的 FILE* 对链接到不同的运行时间。
只要库 API 仅使用原始类型，并且不要尝试 free() 传入指针，或将指针传递到内部 malloc() 内存，他们希望应用程序（或另一个库）释放（）你应该可以。
如果混合使用 c 运行时，很容易陷入“任何事情都可能出错”的 FUD，但您必须记住，库和动态库（.so / .dll / .dylib）传统上是在各种各样的情况下开发的语言：允许用 asm、c、c++、fortran、pascal 等编写的代码通过有效的 CPU 高效二进制接口进行通信。
为什么当 C 链接到 C 时突然恐慌？
于 2010-01-12T12:22:54.950 回答
3
这是一个非常糟糕的计划。避免。要么在 2005 年重新编译库，要么在 2008 年编译应用程序。
于 2009-12-09T09:52:42.603 回答
0
根本不是一个好主意。您无法控制运行时库所做的假设以及它们如何实现某些类型。这更有可能造成不洁的混乱。
于 2009-12-09T10:01:03.517 回答