在Windows上可以这样做(但不建议这样做，因为在不同的c库实例之间传递c标准库对象可能会有问题(，如下所示：
每个可执行映像(EXE或DLL(都可以有自己的静态链接CRT，也可以动态链接到CRT。静态包含在特定映像中或由特定映像动态加载的CRT版本取决于它所使用的工具和库的版本。单个进程可以加载多个EXE和DLL映像，每个映像都有自己的CRT
这可以在Linux上完成吗？
这是假的意思吗？但像Linux这样的通用系统不应该有这样的限制，对吧？例如，如果代码库A和代码库B确实需要不同版本的libc才能正常工作，并且假设它们都为客户端提供了非常简单的C风格API(即在这些API中没有指针参数(，该怎么办？
如果不可能，则无需阅读以下内容。
作为实现这一目标的第一步，当我尝试用静态链接的libc:构建一个共享库时
g++ -fPIC -Wall -fexceptions -g -c main.cpp -o main.o
g++ -shared -static main.o -o libtestCppSharedLib.so
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginT.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a shared object
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
这能在Linux上完成吗？
理论上：是的。在实践中：没有
Linux上可用的libc版本都不支持在单个进程中拥有库的多个副本。
此外，与Windows DLL相比，UNIX和Linux使用非常不同的链接模型。
在Windows下，DLL是一个自包含的单元——只有从中显式导出的函数和变量才能从外部看到，调用DLL中定义的函数将总是导致调用该函数(无符号插入(。
在UNIX模型下，默认情况下会导出共享库中的所有，并且在运行时调用同一库中定义的函数可能会也可能不会解析为该函数。
如果代码库A和代码库B真的需要不同版本的libc才能很好地工作在上呢
libc提供了一个标准接口。如果A需要特定于的版本的libc才能正常工作，那么它就坏了。UNIX的理念是，您应该修复A或B(或两者(。