Bug 435235
Summary: | Java fails to load 64 bit JNI bindings (*.so) located in lib64 folders (java.library.path problem) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Rajesh Krishnan <raj.dev.redhat> |
Component: | java-1.6.0-openjdk | Assignee: | Lillian Angel <langel> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | Keywords: | Reopened |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-04-28 14:29:49 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Rajesh Krishnan
2008-02-28 04:51:37 UTC
This was fixed in the repository, and will be in rawhide soon. java -version java version "1.7.0" IcedTea Runtime Environment (build 1.7.0-b24) IcedTea 64-Bit Server VM (build 1.7.0-b24, mixed mode) $ java LibPath java.library.path=/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib Hence, it is not yet available in b24 (IcedTea in rawhide at the moment) $ ./icedtea/openjdk/build/linux-amd64/bin/java LibPath java.library.path=/notnfs/langel/icedtea/openjdk/build/linux-amd64/lib/amd64/server:/notnfs/langel/icedtea/openjdk/build/linux-amd64/lib/amd64:/notnfs/langel/icedtea/openjdk/build/linux-amd64/../lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib:/usr/lib64:/lib64 This version will be in soon Thanks. Thank you for the Rawhide related info. IMHO your RawHide "java.library.path" is still not correct for the following reasons: 1. The /lib and /usr/lib SHOULD NOT precede /lib64 and /usr/lib64 on x86_64 systems. In orther words, instead of: java.library.path= .... :/lib:/usr/lib:/usr/lib64:/lib64 It should be: java.library.path= .... :/usr/lib64:/lib64:/lib:/usr/lib on x86_64 systems, and it should be like: java.library.path= .... :/lib:/usr/lib on 32-bit systems. 2. The new Rawhide path does not include /usr/local/lib64 folder (again, this should precede before the corresponding /usr/local/lib 32-bit folder in the path). So finally, the correct (my opinion) path should look like: java.library.path= .... :/usr/lib64:/lib64:/usr/local/lib64:/lib:/usr/lib:/usr/local/lib on 64-bit systems and it should look like: java.library.path= .... :/lib:/usr/lib:/usr/local/lib on 32-bit systems. Notice inclusion of both /usr/local/lib64 and /usr/local/lib and their order above. 3. Though strictly not required, for compatibility reasons, it would be a NICE-TO-HAVE feature if we also could include /opt/lib64 and /opt/lib also as one of the java.library.path folders for the sake of some custom built/3rd party packages could use it. At least (1) and (2) above might need to be satisfied in the next build as part of this issue. The (3) could be something the Rawhide devs might want to think about. Hence I am reopening this bug. Thanks, I will look into this for the next release I fixed this in the repository. This will be in the next release. Thx (In reply to comment #0) > 3. Open Question: Does alternative lib64 folders /opt/lib64 folder (and > maybe others) also need to be made available to the JVM? What does SUN say > about LSB folder locations for 64-bit binaries? Applications installed in /opt should set their own LD_LIBRARY_PATH. > 4. Note that the current configuration may be "adequate" for 32-bit Fedora > installations (the non-availibility of /usr/local/lib/ folder for placing JNI > bindings remains an issue though). I don't see the rationale for /usr/local/lib being added to OpenJDK's default LD_LIBRARY_PATH. > 5. I know that the additional path could be specified > using "java -Djava.library.path= ...." option, but that is not the > politically correct way of including the additional system path. Moreover > this would add additional burden on every Java application out there that uses > JNI bindings. JNI-using applications packaged for Fedora can and should use System.load to load the required JNI library directly, instead of System.loadLibrary. > 6. Maybe there should be a symlink called /usr/lib64/libkdejava.so > to /usr/lib64/libkdejava.so.1.0.0 as for libqtjava.so, but that is a > different problem with the packaging of kdebindings package [...] There is a section in the Fedora Java Packaging Guidelines covering this topic: http://fedoraproject.org/wiki/Packaging/Java#head-61a3ee0d05ff616ef9be2021b489610e036fd932 Its recommendations are different than what kdebindings is currently doing (but the guidelines were written after the kdebindings package). kdebindings should eventually be updated to the guidelines. (In reply to comment #5) > (In reply to comment #0) > I don't see the rationale for /usr/local/lib being added to OpenJDK's default > LD_LIBRARY_PATH. "LD_LIBRARY_PATH" should read "dlopen path". |