我有一个在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来解决问题？
或者我只是遗漏了一些非常明显的东西？
由于
编辑：按照Andrew Henle的建议，这是libdvm.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
答案 0 :(得分：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更新45在我的Solaris 9上顺利运行。
因此，libjvm.so显式查找libm.so.1（不只是libm.so，这通常是实际库的默认版本的符号链接），但实际上需要libm.so.2才能工作......
非常感谢安德鲁的提示！