我创建了一个共享库'dlopens'另一个共享库（我不是作者/所有者）
我的共享库，由可执行文件（我不是作者/所有者）“倾斜”
所以层次结构是：exe dlopen是我的库，我的库dlopen是另一个库。
我的图书馆dlopens使用openssl的库。但是，这个库的作者似乎没有链接openssl库 - 也许假设库的用户会。
因此，当我尝试dlopen他们的库时，我遇到了未定义的符号错误。
即使我将openssl库链接到我的库中，我仍然会得到未定义的符号错误。
我的问题是两个：
1）当需要openssl的库被dlopen'ed时，它是否只知道“看”到exe来进行符号解析？
2）我的库中可能缺少特殊的链接器标志，在openssl中链接，我需要吗？
感谢。
答案 0 :(得分：1)
很可能依赖于OpenSSL的库是以动态的方式实现的。您可以使用库.so上的ldd command进行确认。如果您无法在那里发现对OpenSSL的依赖，那么可能意味着库手动加载OpenSSL（本身手动调用dlopen），在这种情况下您无法做太多 - 请联系库维护人员进行修复。
如果依赖项确实显示为ldd输出的一部分，则表示操作系统负责加载它。这方面的规则冗长而复杂，但您需要了解的最重要的事项是LD_LIBRARY_PATH和rpath。
前者允许用户指定系统范围的目录列表，其中加载程序将查找要加载的.so文件。后者是一个内置于库本身的路径列表，将由加载器考虑。
通常需要库维护者设置其rpath，以便在正确安装所有依赖项的情况下正确加载库。毕竟，依靠用户以某种方式设置他们的LD_LIBRARY_PATH并不是很方便。 Here's how you can inspect the .sos rpath
因此，您需要确保以下几点：OpenSSL是否安装在计算机上，是否是正确的版本，以及它是否位于可由装载程序搜索的位置。这可能有点单调乏味，最终可能并不明显的是，这些东西没有加载，但是希望这将足以帮助您找到解决方案。
答案 1 :(得分：0)
问题实际上是具有未定义符号的共享库。这可以起作用，但是不可移植，并且在更换连接器时可能会中断（例如黄金与普通ld）。
如果他们需要符号，他们需要链接到openssl。如果他们想要独立于库（可能是动态切换ABI兼容的openssl forks - 只是一个疯狂的猜测，请注意）他们应该通过dlopen访问openssl实现并通过dlsym手动解析符号。假设动态链接器将神奇地传播＆＃34;符号。
现在，可能有办法让这项工作。
＆＃34;可用性＆＃34; dlopen＆amp; ed库中的符号可以通过the RTLD_LOCAL / RTLD_GLOBAL flags来控制，等等。
Ergo，你可以尝试使用RTLD_GLOBAL来打开openssl，然后再打开需要openssl的库。