【发布时间】：2021-12-26 16:41:16
【问题描述】：
是否可以构建一个依赖于另一个共享库（在我的情况下为 RocksDB - librocksdb.so）但其运行时文件名不同的共享库（使用 g++）？ （例如librocksdb1234.so）。如果是这样，如何做到这一点？
更多上下文
-
我正在为 RocksDB (C++) 实现一个自定义压缩过滤器，我打算通过 JNI 在我的 Java 应用程序中使用它。
-
在 Java 中使用 RocksDB 时，我需要首先调用
RocksDB.loadLibrary()，它将加载 RocksDB 库。 RocksDB JNI jar 带有多个 RocksDB 共享对象（.so 文件），每个架构一个。当我调用此方法时，它将在 jar 中选择正确的共享对象文件，将其复制到临时文件夹，然后使用System.load(...)加载它。复制的共享对象文件使用随机后缀创建。 -
为了开发自定义压缩过滤器，我首先安装了 RocksDB 头文件（这只是调用 RocksDB 项目中的 Makefile 任务，将头文件复制到
/usr/local/include/rocksdb），并将 RocksDB 构建为共享库并将其安装在/usr/local/lib中（同样，这只是对项目中已存在的 Makefile 任务的调用）。 -
要使用自定义压缩过滤器构建共享库，我使用 g++ 如下（用于链接）：
g++ -shared -fPI -Wl,--no-undefined <list-of-object-files> -o libcustom.so -lrocksdb（已安装的 RocksDB 共享库名为librocksdb.so）。 -
当我尝试在我的 Java 应用程序上使用自定义压缩过滤器加载共享库时，它会按预期成功加载（只要存在
librocksdb.so）。 -
但是由于 RocksDB JNI 已经附带了 RocksDB 共享对象文件，我想要的只是使用这些共享对象，而不是我为开发目的安装的
librocksdb.so。所以，我基本上只是删除了librocksdb.so并在我的Java 应用程序中添加了对RocksDB.loadLibrary()的调用。一旦我这样做了，由于librocksdb.so.6: cannot open shared object file: No such file or directory，我将无法加载我的共享库。 -
我验证了 RocksDB 共享对象（来自 jar）已使用
lsof -p <pid>正确加载。 -
据我了解，发生这种情况是因为我使用自定义压缩过滤器的共享对象将在其标头中有一个条目，该条目定义了对名为
rocksdb的库的依赖项（使用objdump -x ...确认）。但是因为RocksDB.loadLibrary()加载的RocksDB共享对象有一个随机的名字，所以不会匹配到需要的依赖。
Dynamic Section:
NEEDED librocksdb.so.6
...
附加问题 在第 8 点中。我假设动态加载将基于共享对象的文件名。这是一个正确的假设吗？或者动态加载是否基于 SONAME？ （我注意到 RocksDB JNI jar 中的共享对象没有定义 SONAME）。
【问题讨论】：
-
如果您只需要在 linux 上运行，您可能可以
LD_PRELOAD挂钩dlopen并将System.load进行的底层调用重定向到librocksdb的系统安装。这是一种丑陋的做法。 -
如果你使用glibc，可以调用
dl_iterate_phdr，查看加载了哪些共享库。 -
可能值得研究
dlopen()和dlsym()(man7.org/linux/man-pages/man3/dlopen.3.html)，它们是手动加载共享库并从中检索函数指针的函数。
标签： c++ g++ dynamic-linking rocksdb dynamic-loading