JNI调用第三方共享库时出现未定义符号错误求助

核心原因分析 #

你的问题本质是共享库的动态依赖加载逻辑导致的：C可执行程序在编译/运行时已经处理了依赖库的查找路径，但Java通过JNI加载共享库时，系统的动态链接器无法定位依赖库中的符号。以下是具体解决方案：

1. 先检查共享库的依赖链 #

用ldd命令确认依赖库是否能被系统正确找到：

ldd libFoo.so

如果输出中出现bar => not found，说明系统找不到包含bar符号的依赖库（比如libBar.so），这是问题的核心。

2. 编译共享库时显式链接依赖库 #

编译依赖其他库的共享库时，必须显式链接依赖库，不能只编译源文件。比如编译libFoo.so时，要把libBar.so链接进去：

# 假设libBar.so在当前目录下
gcc -shared -fPIC -o libFoo.so Foo.c -L./ -lBar

• -L./：指定依赖库的查找路径
• -lBar：链接libBar.so（系统会自动补全前缀lib和后缀.so）

如果省略-lBar，libFoo.so只会记录对bar符号的引用，但不会关联到具体的依赖库，Java加载时自然找不到符号。

3. 配置共享库加载路径 #

临时方案：设置LD_LIBRARY_PATH环境变量

运行Java程序时，把依赖库所在路径加入LD_LIBRARY_PATH（这是Linux动态链接器的全局库路径）：

# 假设依赖库在/mnt/data/singer/c/experiment目录
LD_LIBRARY_PATH=/mnt/data/singer/c/experiment java -Djava.library.path=/mnt/data/singer/c/experiment HelloWorld

注意：java.library.path仅负责让Java找到直接调用的libFoo.so，而libFoo.so依赖的libBar.so需要靠LD_LIBRARY_PATH或rpath来定位。

永久方案：编译时设置rpath

如果不想每次运行都配置环境变量，可以在编译共享库时，通过-Wl,-rpath,$ORIGIN选项让共享库从自身所在目录查找依赖：

gcc -shared -fPIC -o libFoo.so Foo.c -L./ -lBar -Wl,-rpath,$ORIGIN

• $ORIGIN是动态链接器的特殊变量，代表当前共享库所在的目录
• 配置后libFoo.so会自动从自身目录加载libBar.so，无需额外设置环境变量

4. 验证符号是否正确导出 #

用nm命令检查依赖库中的符号是否被正确导出：

nm -D libBar.so | grep bar

如果输出是T bar（T代表全局文本段符号），说明符号正常导出；如果是U bar，说明libBar.so本身没有定义bar，需要检查libBar.so的编译过程。

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