这个问题我之前在做跨依赖项目时真的踩过坑，尤其是碰到这种子库版本完全不兼容、符号冲突的情况，太闹心了。结合你提到的foo和bar（也就是librealsense相关组件）支持静态/动态构建的情况，给你整理几个实际可行的解决思路：

方案1：静态编译其中一个依赖并做全局符号重命名 #

这是我最常用的方案，不需要改太多源码就能解决冲突：

• 先选其中一个依赖（比如foo），将它依赖的baz A版本静态编译到foo的库中，确保不会动态拉取系统里的baz库
• 对静态编译的baz A版本做全局符号重命名，比如把所有baz_开头的符号批量改成foo_baz_，彻底和bar依赖的baz B版本符号划清界限
• 具体操作可以用这些工具：
  • 编译baz A时，用GCC的-fvisibility=hidden配合版本脚本（.map文件），只导出foo需要的符号，隐藏其他baz符号
  • 或者用objcopy --redefine-sym old_sym=new_sym批量替换符号，比如objcopy --redefine-sym baz_init=foo_baz_init libbaz.a
• 最后把处理好的foo静态库链接到你的mylib，同时正常链接bar（bar可以是动态或静态，只要它依赖的baz B版本符号不重叠就行）

方案2：用命名空间隔离（需修改baz源码） #

如果能拿到baz的源码，这个方案更优雅：

• 给baz A版本的所有代码套上专属命名空间，比如namespace foo_baz { ... }，然后重新编译这个修改后的baz A
• 让foo重新链接这个带命名空间的baz A，这样foo调用的所有baz符号都会带上foo_baz::前缀，和bar依赖的baz B的全局符号完全隔离
• 要是foo本身提供了编译选项指定依赖的baz命名空间，直接开启选项就行，不用自己改源码

方案3：将其中一个依赖打包成独立动态库，通过动态加载调用 #

这个方案适合不想改编译流程的场景：

• 把foo和它依赖的baz A版本打包成一个独立的动态库foo_with_bazA.so，确保这个库内部的baz符号不会对外暴露
• 在你的mylib里不直接链接这个库，而是用dlopen()在运行时加载它，再通过dlsym()获取你需要的foo相关符号
• 这样foo_with_bazA.so里的baz A符号会被隔离在自己的地址空间，完全不会和bar的baz B符号冲突
• 缺点是需要手动管理动态加载的符号，代码里要写更多的加载、错误处理逻辑，不过胜在不用动依赖的编译配置

方案4：尝试适配兼容层（可行性较低，仅作参考） #

虽然你说两个版本不兼容，但可以再仔细核对差异：

• 看看bar是不是只用到了baz B里和A不兼容的一小部分功能，能不能给bar写个适配层，把它对baz B的调用转成调用baz A的对应功能
• 或者查一下foo/bar的最新版本（比如你提到的librealsense 0.0.6），有没有更新依赖的baz版本，刚好能和另一个依赖的baz版本兼容

最后提醒几点 #

• 完成后一定要用nm -D mylib.so或者objdump -x mylib.so检查符号表，确认没有重复的baz相关符号
• 静态编译时要注意链接选项，确保foo只链接静态的baz A，别不小心拉进动态版本的baz

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