我有以下场景： foo直接依赖bar，bar依赖baz。 foo 的 RPATH 为 $ORIGIN/lib，其中 bar.so 和 baz.so 位于其中。 bar 的 RUNPATH 为 /some/unimportant/dir/with/no/baz.
当我 ldd foo 时，我得到： bar.so -> $ORIGIN/lib baz.so -> 未找到
在这种情况下，我预计在搜索baz时，链接器会先搜索bar的RUNPATH，没有找到，然后在foo的RPATH中查找。然而，事实并非如此，我真的想不通为什么。我注意到，虽然在相同情况下与 RPATH 的其他一些直接依赖关系（即不在直接依赖关系的 RPATH 中的间接依赖关系）起作用，因为链接器将在 foo 的 RPATH 中查找。不确定这是否相关。
我试图通过使 baz 成为 foo 的直接依赖来解决这个问题。 所以现在的场景是： foo -> bar baz 酒吧 -> 巴兹
从 ldd 显示的意义上说，这是有效的： bar.so -> $ORIGIN/lib baz.so -> $ORIGIN/lib
但是，我不确定，当程序运行并且bar需要baz时，它是否还会尝试在bar的RUNPATH中寻找它？会不会找不到就停止程序执行了？
这是我不完全理解链接在这种情况下如何工作的地方。 是顺序的吗？从某种意义上说，它将尝试链接 bar，看到 bar 对 baz 具有依赖性，然后尝试在 bar 的 RUNPATH 中查找 baz。然后它转到 baz（b/c 这是列表的下一个直接依赖项）。 还是某种共享库池？同样，它同时整理出所有依赖项和子依赖项，并将它们放入同一种库池中。所以它将首先遍历所有依赖项，并将它们添加到这个“池”中。当它查看间接依赖项时，它会看到 baz 已经在“池”中，因此它将在那里使用 baz，而不是试图在 bar 的 RUNPATH 中找到它。