Solaris 9上的Java 1.6.0“U 45返回重新定位错误”；符号“fmodf：未找到引用符号”；

我有一个java应用程序运行在Solaris9（Solaris10全局服务器中的品牌区域）中

我确信（从日志中）应用程序在JDK 1.6.045上运行了几个月：

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的建议，这是libjvm的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

---

好的，解决了。但这很奇怪

正如Andrew Henle在评论中所建议的那样，我仔细检查了

root@server # truss -f -a -e -l -f -rall -wall -o truss_jdk_1.6.0_45.txt /usr/bin/java -version

并确认包含符号

\uuu fmodf

的数学库在运行时由

libjvm调用。因此

，在系统的默认位置找到它之前在多个位置查找它：

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

才能工作

---

非常感谢安德鲁的提示

您已经为

/usr/bin/java

发布了

ldd

输出。该输出不包括任何

libjvm.so

，但错误消息是针对

/usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/libjvm.so

。该共享对象的

ldd-rv

输出是什么？（添加

-r

以强制实际的符号查找，这就是您看到的问题。请参阅）嗨，安德鲁，谢谢您的回复。我也试过了，而且看起来很好。。。顺便说一句，我编辑了问题并添加了您建议的输出。这根本没有显示

libm。所以

。JVM代码可能是在具有不同链接器选项/环境变量的库中运行时链接。尝试

truss-f-a-e-l-o/path/to/output/filejava-version

。这可能会产生大量输出，显示为加载和运行时链接启动JVM所需的所有共享对象而进行的所有系统调用。在这些数据中的某个地方应该有一条线索，说明对

libm.的需求从何而来。修复可能必须是JVM的升级-1.6.045是一个古老的版本，它在重新启动后停止工作。补丁/更新？已解决。我自己发布了解决方案。谢谢你的提示，安德鲁。
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

/.SUNWnative/lib/libm.so.1
/.SUNWnative/lib/libm.so.2

root@server # ln -s /.SUNWnative/lib/libm.so.2 /usr/jdk/instances/jdk1.6.0/jre/lib/sparc/server/libm.so.1