一个程序使用的多个共享库可以使用不同的静态链接库吗？

如何解决一个程序使用的多个共享库可以使用不同的静态链接库吗？

在 Windows 上可以这样做（虽然不推荐，因为在不同的 c 库实例之间传递 c 标准库对象可能会出现问题），例如 this：

每个可执行映像（EXE 或 DLL）都可以有自己的静态链接 CRT，或者可以动态链接到 CRT。特定图像中静态包含或动态加载的 CRT 版本取决于构建它的工具和库的版本。单个进程可能加载多个 EXE 和 DLL 图像，每个图像都有自己的 CRT

这可以在 Linux 上完成吗？

this 是假的吗？但是像Linux这样的一般系统不应该有这样的限制吧？例如，如果代码库 A 和代码库 B 确实需要不同版本的 libc 才能正常工作，并且假设它们都为客户端提供非常简单的 C 风格 API（即这些 API 中没有指针参数），该怎么办？

如果不可能，则无需阅读以下内容。

作为实现这一目标的第一步，当我尝试使用静态链接的 libc 构建共享库时：

    SRI       MP_START  MP_END  TRUCK_PCT
0   17031021__  0.00    0.100   
1   03291236__  0.00    0.050
2   200006165__ 0.00    0.120
3   00000009__  52.36   52.394
4   00000009__  51.78   52.360   7%
5   00000009__  49.09   51.780   7%
6   00000009__  48.76   48.760
7   00000015__  15.45   15.480   7%

解决方法

这可以在 Linux 上完成吗？

理论上：是的。在实践中：没有。

Linux 上可用的 libc 版本均不支持在单个进程中拥有库的多个副本。

此外，与 Windows DLL 相比，UNIX 和 Linux 使用非常不同的链接模型。

在 Windows 下，DLL 是一个自包含单元——只有从它显式导出的函数和变量从外部可见，调用 DLL 中定义的函数将总是导致调用那个函数（无符号插入）。

在 UNIX 模型下，共享库中的所有内容默认都是导出的，调用在同一库中定义的函数可能会也可能不会在运行时解析为该函数。

如果代码库 A 和代码库 B 确实需要不同版本的 libc 才能正常工作，该怎么办

libc 提供了一个标准接口。如果 A 需要一个特定版本的 libc 才能正常工作，那么它就坏了。 UNIX 理念是您应该修复 A 或 B（或两者）。