2

我有一个在 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 所建议的，这是 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
4

1 回答 1

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/.

当我链接时/.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工作......

非常感谢安德鲁的提示！

于 2016-10-26T14:11:37.517 回答