如何将Linux共享库预链接依赖实现自包含以用于JNI打包？

一、能否实现需求？链接器支持此类操作吗？ #

完全可以实现，主要通过静态链接或**动态库合并（打包）**两种方式，链接器及相关工具支持这类操作：

1. 静态链接（优先推荐，若有静态库资源） #

如果第三方提供了依赖库的静态版本（如libgdal.a、libproj.a等），可以重新链接libpdalcpp.so，将所有依赖的代码静态嵌入到目标库中：

# 假设所有静态库位于链接器可检索路径下
g++ -shared -o libpdalcpp_selfcontained.so libpdalcpp.o -lgdal -lproj -lgeotiff -lxml2 -lz -static-libstdc++

注意：

• 需确认依赖库的许可协议允许静态链接（如GPL类协议可能有额外要求）
• 系统核心库（如libc.so）通常不建议静态链接，避免引发兼容性问题

2. 动态库合并（无静态库时的替代方案） #

若仅能获取动态库，可借助ld、patchelf等工具将依赖的动态库合并到目标库中：

操作步骤示例：

1. 收集所有依赖的动态库路径：

ldd libpdalcpp.so.17.0.0 | grep -v 'ld-linux' | awk '{print $3}' > dependencies.txt

2. 合并主库与依赖库为单个目标文件，再编译为共享库：

ld -r -o libpdalcpp_merged.o libpdalcpp.so.17.0.0 $(cat dependencies.txt)
g++ -shared -o libpdalcpp_selfcontained.so libpdalcpp_merged.o

3. 修正新库的动态链接标识：

patchelf --set-soname libpdalcpp_selfcontained.so libpdalcpp_selfcontained.so

该方式本质是将多个动态库的代码合并为一个，运行时无需加载外部依赖。

二、这个思路是否可行？ #

思路完全可行，尤其适配Java应用打包JNI库的场景：

• 从插件设计角度，JVM中的JNI库确实需要尽可能自包含，避免依赖运行环境的系统库，否则极易出现“跨环境运行缺库报错”的问题，这与你提到的JRE/CLR插件自包含的原则一致。
• 共享库的模块化是系统级设计目标，但对于应用级插件（如JNI库），自包含是更优选择，能大幅提升部署便利性。
• 需注意的细节：
  • 合并后的库体积会增大，需权衡部署包大小与兼容性
  • 需测试合并后的库在目标容器环境的兼容性，比如GLIBC版本是否匹配（若依赖的系统库版本过高，可能在旧容器中运行失败）
  • 部分依赖库可能依赖系统配置资源（如GDAL的投影文件），这类资源也需一同打包到JAR中，运行时指定加载路径

内容的提问来源于stack exchange，提问作者Christian Fuchs