一个大的 Target 包含多个不同厂商的 so，导致名字冲突的问题？

[James369]

一个比较大的 Target ，依赖了 A 厂商和 B 厂商提供的 2 个模块（主要以 so 形式，称之为 A.so 和 B.so ），依赖关系如下：

Target: ( A.so + B.so + xxx)

现在的问题是，恰巧 A,B 厂商都使用了同样的子模块，假设都使用了 ffmpeg 技术，此时有 2 种场景： 一种走动态库，如下依赖：

A.so: (ffmpeg.v1.so)
B.so: (ffmpeg.v2.so)

问题 1：此时如果两家使用 ffmpeg 的版本不管一致或不一致，能否编译链接成功，最终 Target 是否会有问题？

另一种走静态库，如下依赖：

A.so: (ffmpeg.v1.a)
B.so: (ffmpeg.v2.a)

问题 2：此时不管 ffmpeg 的版本一致或不一致，能否编译链接成功，最终 Target 是否会有问题？

引申问题 3：是否有某种类似沙盒 /命名空间的技术，将不同厂商的 so 限定在各自的命名空间之内，不管他们依赖何种代码模块，都可以成功链接进 Target 。这样子就可以集成任意多个厂商的库，而无需担心冲突的问题。

[Monad]

emmm 怎么看起来像是面试题?

[rev1si0n]

看看能不能用相同版本呗，逻辑不复杂或许直接链接到同一个都能用，塞两个 ffmpeg 不大吗，你可以再塞两个 opencv 看看

[James369]

@Monad 你是在夸我排版好看，措辞清晰吗？嘿嘿

[James369]

@rev1si0n 这里说 ffmpep 只是个举例，更多情况可能是某某 json 处理库，网络库，等等非一流的库。

[nuk]

还真的遇到过一样的问题，openssl1.0 和 openssl1.1 的问题，最后做了静态链接，如果动态链接的话可以看看这个
https://blog.habets.se/2012/05/Shared-libraries-diamond-problem.html ，so 要重新编译修改导出符号。
windows 上就好解决了，写个 manifest 就好。

[James369]

@nuk 不错。最近比较忙，改天有空做下实验