我有一个在Solaris 9（Solaris 10全局数据库内的品牌区域）中运行的Java应用程序。
root@server # cat /etc/release
Solaris 9 4/03 s9s_u3wos_08 SPARC
Copyright 2003 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 25 February 2003
...
root@server # isainfo -v
64-bit sparcv9 applications
32-bit sparc applications
我从日志中肯定知道该应用程序过去在JDK 1.6.0_45上运行了几个月：
root@server # pkginfo | grep -i jdk
system SUNWj2dem JDK 1.2 demo programs
system SUNWj2man JDK 1.2 man pages
system SUNWj2rt JDK 1.2 run time environment
system SUNWj3irt JDK 1.4 I18N run time environment
system SUNWj6cfg JDK 6.0 Host Config. (1.6.0_45)
system SUNWj6dev JDK 6.0 Dev. Tools (1.6.0_45)
system SUNWj6dvx JDK 6.0 64-bit Dev. Tools (1.6.0_45)
system SUNWj6jmp JDK 6.0 Man Pages: Japan (1.6.0_45)
system SUNWj6man JDK 6.0 Man Pages (1.6.0_45)
system SUNWj6rt JDK 6.0 Runtime Env. (1.6.0_45)
system SUNWj6rtx JDK 6.0 64-bit Runtime Env. (1.6.0_45)
现在，重新启动后，Java 6返回错误，而其他版本仍然可以正常运行：
root@server # java -version
dl failure on line 685Error: failed /usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/libjvm.so, because ld.so.1: java: fatal: relocation error: file /usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/libjvm.so: symbol __fmodf: referenced symbol not found
我知道这在Solaris 8和/或JDK 7中是预期的行为，但是Oracle证明JDK 6与Solaris 9兼容，因此我无法真正弄清楚发生了什么。我已经坚持了两天，尝试了任何解决方法，但是没有运气。
解决了所有需要的系统库：
root@server # ldd -v /usr/bin/java
find object=/usr/lib/secure/s9_preload.so.1; required by /usr/jdk/instances/jdk1.6.0/bin/java
/usr/lib/secure/s9_preload.so.1
find object=libthread.so.1; required by /usr/jdk/instances/jdk1.6.0/bin/java
libthread.so.1 => /usr/lib/libthread.so.1
find version=libthread.so.1
libthread.so.1 (SISCD_2.3a) => /usr/lib/libthread.so.1
find object=libjli.so; required by /usr/jdk/instances/jdk1.6.0/bin/java
libjli.so => /usr/jdk/instances/jdk1.6.0/bin/../jre/lib/sparc/jli/libjli.so
find version=libjli.so
libjli.so (SUNWprivate_1.1) => /usr/jdk/instances/jdk1.6.0/bin/../jre/lib/sparc/jli/libjli.so
find object=libdl.so.1; required by /usr/jdk/instances/jdk1.6.0/bin/java
libdl.so.1 => /usr/lib/libdl.so.1
find version=libdl.so.1
libdl.so.1 (SUNW_0.8) => /usr/lib/libdl.so.1
find object=libc.so.1; required by /usr/jdk/instances/jdk1.6.0/bin/java
libc.so.1 => /usr/lib/libc.so.1
find version=libc.so.1
libc.so.1 (SUNW_0.7) => /usr/lib/libc.so.1
libc.so.1 (SUNWprivate_1.1) => /usr/lib/libc.so.1
find object=libc.so.1; required by /usr/lib/secure/s9_preload.so.1
find object=libc.so.1; required by /usr/lib/libthread.so.1
find version=libc.so.1
libc.so.1 (SUNW_1.21.2) => /usr/lib/libc.so.1
libc.so.1 (SUNWprivate_1.1) => /usr/lib/libc.so.1
find object=libdl.so.1; required by /usr/lib/libthread.so.1
find version=libdl.so.1
libdl.so.1 (SUNWprivate_1.1) => /usr/lib/libdl.so.1
find object=libc.so.1; required by /usr/jdk/instances/jdk1.6.0/bin/../jre/lib/sparc/jli/libjli.so
find version=libc.so.1
libc.so.1 (SUNW_0.7) => /usr/lib/libc.so.1
find object=libdl.so.1; required by /usr/lib/libc.so.1
find version=libdl.so.1
libdl.so.1 (SUNW_1.4) => /usr/lib/libdl.so.1
libdl.so.1 (SUNWprivate_1.1) => /usr/lib/libdl.so.1
object=/usr/lib/libdl.so.1; filter for /usr/lib/ld.so.1
object=/usr/lib/libc.so.1; filter for /usr/platform/$PLATFORM/lib/libc_psr.so.1
find object=/usr/platform/SUNW,Sun-Blade-T6320/lib/libc_psr.so.1; required by /usr/lib/libc.so.1
/usr/platform/SUNW,Sun-Blade-T6320/lib/libc_psr.so.1
因此，我必须假定由于某种原因它们已经过时并且没有实现符号__fmodf。但是它以前是如何工作的？
据我了解，fmodf（）是libm库中的一种方法。由于默认情况下Solaris 9将libm.so链接到libm.so.1，因此我也尝试使用以下方法覆盖数学库：
root@server # LD_PRELOAD=/.SUNWnative/lib/libm.so.2 java -version
但是仍然没有运气。
是否有任何方法可以覆盖该符号和/或以某种“兼容性”模式运行Java以解决此问题？
还是我只是缺少一些非常明显的东西？
谢谢
编辑：正如安德鲁·亨利建议，这是libjvm.so的ldd的完整输出：
root@server # ldd -rv /usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/libjvm.so
find object=libc.so.1; required by /usr/lib/secure/s9_preload.so.1
libc.so.1 => /usr/lib/libc.so.1
find object=libdl.so.1; required by /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
find version=libdl.so.1
libdl.so.1 (SUNW_1.4) => /usr/lib/libdl.so.1
libdl.so.1 (SUNWprivate_1.1) => /usr/lib/libdl.so.1
object=/usr/lib/libc.so.1; filter for /usr/platform/$PLATFORM/lib/libc_psr.so.1
find object=/usr/platform/SUNW,Sun-Blade-T6320/lib/libc_psr.so.1; required by /usr/lib/libc.so.1
/usr/platform/SUNW,Sun-Blade-T6320/lib/libc_psr.so.1
object=/usr/lib/libdl.so.1; filter for /usr/lib/ld.so.1
...
root@server # ldd -ss /usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/libjvm.so
find object=libc.so.1; required by /usr/lib/secure/s9_preload.so.1
search path=/usr/openwin/lib:/usr/local/lib:/usr/local/ssl/lib (LD_LIBRARY_PATH)
trying path=/usr/openwin/lib/libc.so.1
trying path=/usr/local/lib/libc.so.1
trying path=/usr/local/ssl/lib/libc.so.1
search path=/usr/lib (default)
trying path=/usr/lib/libc.so.1
libc.so.1 => /usr/lib/libc.so.1
find object=libdl.so.1; required by /usr/lib/libc.so.1
search path=/usr/openwin/lib:/usr/local/lib:/usr/local/ssl/lib (LD_LIBRARY_PATH)
trying path=/usr/openwin/lib/libdl.so.1
trying path=/usr/local/lib/libdl.so.1
trying path=/usr/local/ssl/lib/libdl.so.1
search path=/usr/lib (default)
trying path=/usr/lib/libdl.so.1
libdl.so.1 => /usr/lib/libdl.so.1
object=/usr/lib/libc.so.1; filter for /usr/platform/$PLATFORM/lib/libc_psr.so.1
find object=/usr/platform/SUNW,Sun-Blade-T6320/lib/libc_psr.so.1; required by /usr/lib/libc.so.1
/usr/platform/SUNW,Sun-Blade-T6320/lib/libc_psr.so.1
object=/usr/lib/libdl.so.1; filter for /usr/lib/ld.so.1
最佳答案
好，解决了不过，这很奇怪。
正如Andrew Henle在评论中所建议的那样，我仔细检查了
root@server # truss -f -a -e -l -f -rall -wall -o truss_jdk_1.6.0_45.txt /usr/bin/java -version
并确认包含符号
__fmodf的数学库在运行时由libjvm.so调用，该库在多个位置进行查找，然后在系统的默认位置查找它：24757/1: stat("/usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/libm.so.1", 0xFFBFE910) Err#2 ENOENT
24757/1: stat("/usr/jdk/instances/jdk1.6.0/jre/lib/sparc/libm.so.1", 0xFFBFE910) Err#2 ENOENT
24757/1: stat("/usr/jdk/instances/jdk1.6.0/jre/../lib/sparc/libm.so.1", 0xFFBFE910) Err#2 ENOENT
24757/1: stat("/usr/openwin/lib/libm.so.1", 0xFFBFE910) Err#2 ENOENT
24757/1: stat("/usr/local/lib/libm.so.1", 0xFFBFE910) Err#2 ENOENT
24757/1: stat("/usr/local/ssl/lib/libm.so.1", 0xFFBFE910) Err#2 ENOENT
24757/1: stat("/usr/lib/libm.so.1", 0xFFBFE910) = 0
24757/1: resolvepath("/usr/lib/libm.so.1", "/usr/lib/libm.so.1", 1023) = 18
24757/1: open("/usr/lib/libm.so.1", O_RDONLY) = 3
文件
/usr/lib/libm.so.1实际上存在于系统上，但是我还注意到在其他地方安装了相同数学库的其他版本：/.SUNWnative/lib/libm.so.1
/.SUNWnative/lib/libm.so.2
因此，我尝试通过将它们软链接到
/usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/来为Java提供反馈。当我链接
/.SUNWnative/lib/libm.so.1时，什么都没有改变，但是出于绝望，我尝试了最肮脏的把戏：root@server # ln -s /.SUNWnative/lib/libm.so.2 /usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/libm.so.1
令人惊讶的是，这成功了。现在，Java 6 update 45在我的Solaris 9上可以平稳运行。
因此，
libjvm.so明确寻找libm.so.1（不仅仅是libm.so，通常是实际库的默认版本的符号链接），但实际上需要libm.so.2才能工作。非常感谢安德鲁的提示！