Linux ELF环境下C++多共享库加载的规范主体与最佳实践

场景描述 #

• app 直接链接 libcore.so.1
• app 的依赖库 libphysics.so 链接 libcore.so.2
• app 的另一依赖库 librender.so 同样链接 libcore.so.2

已知 libcore.so.1 与 libcore.so.2 ABI不兼容，且拥有不同的SONAME。

核心疑问 #

我想明确两个层面的问题：

1. Linux动态加载器在这种场景下会如何处理？
2. 采用何种设计与责任划分机制，能避免或减少符号冲突及进程崩溃？

我当前的理解是：加载器会因SONAME不同同时加载两个版本的libcore，但由于部分符号重名且无法自动隔离，仍会发生符号冲突。如果这个理解正确，那么谁该负责避免这类问题？是libcore的开发者？还是app的开发者？是否需要在libcore.so中加入运行时检测，当检测到其他版本的库加载时立即终止进程？

希望了解的工程化最佳实践 #

我需要明确C++/Linux共享库生态中的常规最佳实践，重点包括：

• ELF加载器的具体行为逻辑
• SONAME与版本号的规范用法
• 符号可见性控制与冲突规避方案
• 应用及其依赖库共用共享依赖的架构设计规则

注：我不需要LD_PRELOAD这类临时 workaround，只寻求长期的正确设计方案。若表述有不清楚的地方，请告知我补充细节。

内容的提问来源于stack exchange，提问作者Dean