Description of problem: Paths specified by java.library.path are missing some directories. Simple reproducer: class jlibpath { public static void main(String args[]) { System.out.println(System.getProperty("java.library.path")); } } Version-Release number of selected component (if applicable): java-1.7.0-openjdk-1.7.0.0-0.1.20110803.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. Compile above reproducer 2. Run: /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java testpath Actual results: /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib Expected results: Something similar to java-1.6.0-openjdk output which is: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib Additional info:
To be exact I expected something like this from openjdk 1.7.0: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
The culprit is: #define REG_DIR "/usr/java/packages" in src/os/linux/vm/os_linux.cpp. The others have gone because library loading was cleaned up. The obvious thing to do from my perspective is fix this to be the install path, making it configurable. On Fedora, /usr/java/packages would be replaced with /usr/lib/jvm/java-1.7.0-openjdk for example. Do we actually need all three i.e. <install>/lib/amd64 <jre_install>/lib/amd64 <jre_install>/lib/amd64/server Based on existing content, <jre_install>/jre/lib/amd64 seems sufficient. Are some packages actually broken as a result of this change?
This problem was spotted by me when searching a way how to get path to JDK shared libraries to be able to link them to my native C code (i.e. the `-L' option passed to gcc or ld). I found java.library.path as the best approach which does not work for openjdk-1.7 obviously. If you have no better way to get these paths, I would appreciate if all paths kept in the list. E.g. libjvm.so resides under `server' directory in openjdk-1.6.
java-1.7.0-openjdk-1.7.0.3-2.1.fc16.2 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.3-2.1.fc16.2
java-1.7.0-openjdk-1.7.0.3-2.1.fc17.2 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/java-1.7.0-openjdk-1.7.0.3-2.1.fc17.2
I'm sorry the returned path are still bad: $ rpm -qf /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java java-1.7.0-openjdk-1.7.0.3-2.1.fc16.2.x86_64 $ /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java -version java version "1.7.0_b147-icedtea" OpenJDK Runtime Environment (fedora-2.1.fc16.2-x86_64) OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode) $ /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java JavaConfig --libs-only-L -L/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/lib/amd64 -L/usr/lib64 -L/lib64 -L/lib -L/usr/lib $ LANG=en stat /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/lib/amd64 stat: cannot stat `/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/lib/amd64': No such file or directory Expected paths for this build are: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/lib/amd64/ /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/lib/amd64/server/ So not only the correct paths are missing, also given path is invalid.
It is weird that the jre dir is not being added. It was doing so in the local builds I did. Sorry about that. Do you also need the server/ patch by the way, or would /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/lib/amd64/ suffice? Thanks for testing it. I will work on this and confirm with the build rpm before pushing again.
Yes, I need the server path because it contains libjvm.so. I need all paths where JVM dynamic libraries reside to pass these paths to native linker.
Looking at what the OpenJDK6 had (hs20): http://hg.openjdk.java.net/hsx/hsx20-gate/master/file/f0f676c5a2c6/src/os/linux/vm/os_linux.cpp It seems like it too does not add $JAVA_HOME/jre/lib/... to the path. I think the issue was that the launcher no longer sets LD_LIBRARY_PATH, due to this commit: http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/de45eac5670e Thus updating java.library.path seems to be incorrect, as the setting code has not changed. It is LD_LIBRARY_PATH that has changed. Updating LD_LIBRARY_PATH is not a good idea IMO. I looked into your problem more and I think that a better solution is to use something like: String libdir = System.getProperty("java.home") + "/lib/" + System.getProperty("os.arch"); String libjvmdir = System.getProperty("java.home") + "/lib/" + System.getProperty("os.arch") + "/server"; System.out.println(libdir); System.out.println(libjvmdir); I am going to mark this as WONTFIX, but please feel to re-open if you disagree.
Yes, the LD_LIBRARY_PATH changes caused this change, as mentioned in comment #2. I still think there's a case for changing /usr/java/packages to something we actually use, but that's a separate issue.
(In reply to comment #10) > Yes, the LD_LIBRARY_PATH changes caused this change, as mentioned in comment > #2. > > I still think there's a case for changing /usr/java/packages to something we > actually use, but that's a separate issue. Ah sorry, I thought you had meant that loading was cleaned up in os_linux.cpp
Yeah, sorry, it could have been clearer. Thought this bug was long dead :-)
(In reply to comment #9) > Looking at what the OpenJDK6 had (hs20): > > http://hg.openjdk.java.net/hsx/hsx20-gate/master/file/f0f676c5a2c6/src/os/linux/vm/os_linux.cpp > > It seems like it too does not add $JAVA_HOME/jre/lib/... to the path. > You have beautiful comment at os::init_system_properties_values(): // The next steps are taken in the product version: // // Obtain the JAVA_HOME value from the location of libjvm[_g].so. // This library should be located at: // <JAVA_HOME>/jre/lib/<arch>/{client|server}/libjvm[_g].so. // // If "/jre/lib/" appears at the right place in the path, then we // assume libjvm[_g].so is installed in a JDK and we use this path. // // Otherwise exit with message: "Could not create the Java virtual machine." // // The following extra steps are taken in the debugging version: // // If "/jre/lib/" does NOT appear at the right place in the path // instead of exit check for $JAVA_HOME environment variable. // // If it is defined and we are able to locate $JAVA_HOME/jre/lib/<arch>, // then we append a fake suffix "hotspot/libjvm[_g].so" to this path so // it looks like libjvm[_g].so is installed there // <JAVA_HOME>/jre/lib/<arch>/hotspot/libjvm[_g].so. // // Otherwise exit. // // Important note: if the location of libjvm.so changes this // code needs to be changed accordingly. > Updating LD_LIBRARY_PATH is not a good idea IMO. I looked into your problem > more and I think that a better solution is to use something like: > > String libdir = System.getProperty("java.home") + "/lib/" + > System.getProperty("os.arch"); > String libjvmdir = System.getProperty("java.home") + "/lib/" + > System.getProperty("os.arch") + "/server"; > > System.out.println(libdir); > System.out.println(libjvmdir); > So you suggest me to duplicate the hard-coded path mess from your code. This is exactly what I do not want. Especially because of last paragraph of the comment: // Important note: if the location of libjvm.so changes this // code needs to be changed accordingly. > I am going to mark this as WONTFIX, but please feel to re-open if you disagree. Can you guarantee the locations will not change and this layout is valid on all platforms? Or could you provide better way how to get _all_ java library paths?
And of course the java.library.path property (http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#getProperties()) returns non-existent path on x86_64 now. So at least this is still broken.
It is not my code, it was written by Oracle/Sun folks. java.library.path is meant to contain JNI libraries loaded *by the jvm*. What you are suggesting (adding the extra paths that 6 adds, so that you can link against Java) would be an incorrect use of it. The fact that 6 was appending those paths was a hack and that is why 7 no longer does it. As for how to get all the library paths, the issue is that there is no pkg-config file for the JDK. I discussed this briefly with Omair Majid (on cc) and while adding one is easy enough, the problem there is that there is no generally accepted name that we can use for the .pc file that is common across all distros, which means we are back to patching dependent code in Fedora to use that specific .pc name.
Can you explain how you'd foresee a pkg-config file for OpenJDK in more detail? If we added such a thing to IcedTea (and possibly upstream to OpenJDK), it would make its way (with time) to all distros. I don't see where the "we can only change Fedora" argument comes in at all.
Icedtea may be used by many distros, but it is still not guaranteed to be used by all. For upstream dependent projects to start using something, it has to be on most if not all. That said, it is not impossible -- I just meant that it needs some more thought along those lines rather than just creating a dropping in a .pc file in the RPM as a quick fix. As for the contents of it, I had roughly something like this in mind: prefix=/usr/lib/jvm/java-1.7.0... libdir=${prefix}/jre/lib/<arch>/server/ includedir=${prefix}/include/ Name: <name> Description: ... Version: 1.X.Y Libs: -L${libdir} -ljvm Cflags: -I${includedir}
Deepak, thanks you explaining the java.library.path semantic. Once you put relevant value to the property (if there is standardized search path for JNI libraries, then that one; otherwise let it null or empty), you can close this bug report. You can consider the pkg-config file as new feature and track it with different bug report. I'm not expert in calling JVM from native applications. I just like to see portable way how to compile such applications (to prevent from this: http://pkgs.fedoraproject.org/gitweb/?p=pl.git;a=blob;f=pl.spec;h=6323418356c6ccc3632828408a2bb3b4c6014bd6;hb=f9276e466f7d2124e9a6ef94dca6aef1abf509cb#l166). The upper sketch looks good. I'm not sure -ljvm is the only needed library. E.g. SWI Prolog links to -ljava -ljvm -lverify. If there are different use cases, you can create multiple pkg-config files or you can add more pkg-config variables that can queried by "pkg-config --variable".
IcedTea (note capitalisation) is used by all the major distros, and it's at least a start (better than writing off the idea). As I say, getting it into OpenJDK would be ideal, but harder. We already have a .desktop file being generated using similar data, so this doesn't look too hard to implement. libdir would need more than just the one directory. Can that field be a list? I guess: libdir=${prefix}/jre/lib/${arch} Libs: -L${libdir} -L${libdir}/client -L${libdir}/server would be a start, though there are others in there too.
Ah, yes we will need libdir itself too, in addition to client/ or server/ . As for adding both, we always ship the server -- is there a case where we ship client only? if not, I don't know if we need the client in the -L path there
(In reply to comment #20) > Ah, yes we will need libdir itself too, in addition to client/ or server/ . As > for adding both, we always ship the server -- is there a case where we ship > client only? if not, I don't know if we need the client in the -L path there The path here determines which jvm the JNI programs will start up. Even if we (Fedora) never ship client/ only, do we always want JNI code to star the server vm? Also, I think the order in which -L${libdir}/client -L${libdir}/server matters. As for IcedTea, it can get more complicated. With the --with-additional-vms= configure option, you can get zero/, jamvm/, cacao/ and (possibly) others.
There is some interesting discussions about this in some of the mailing lists. I'm not going to repeat them here, but I think someone should mention some of the key findings. First off, it seems this bug causes severe problems in that it breaks common applications such as elluminate and javadjvu, because libraries such as libjawt are not loaded. (Javadjvu is opensource, you can find it at http://javadjvu.foxtrottechnologies.com . Versions of this applet are used on sights such as archive.org.) Until this is fixed, a workaround is to use a wrapper script for javaws and java that add appropriate libraries into the LD_LIBRARY_PATH. According to: http://lwjgl.org/forum/index.php/topic,4085.msg22061.html#msg22061 Not loading the libraries was a deliberate update According to Andrew Haley: (I am paraphasing below.) > However, breaking awt was probably not intentional. In particular Toolkit.getDefaultToolkit() should just work without a need to adjust library paths and such.) > > The patch says > > > All other required > > + * libraries are loaded by the runtime linker, by virtue of the $ORIGIN paths > > + * baked into the shared libraries, by the build infrastructure at compile time. > > which is not happening. Bill
(In reply to comment #22) > There is some interesting discussions about this in some of the mailing > lists. I'm not going to repeat them here, but I think someone should > mention some of the key findings. First off, it seems this bug causes > severe problems in that it breaks common applications such as elluminate and > javadjvu, because libraries such as libjawt are not loaded. (Javadjvu is > opensource, you can find it at http://javadjvu.foxtrottechnologies.com . > Versions of this applet are used on sights such as archive.org.) Those are actually two separate issues. The libjawt breakage has been fixed in OpenJDK: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f003387c33ad More background about this bug is availabe at: http://mail.openjdk.java.net/pipermail/build-dev/2012-July/006486.html The Javadjvu applet not working was a (completely unrelated) bug in IcedTea-Web and fixed there: http://icedtea.classpath.org/hg/icedtea-web/rev/924a83097ed7
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
How about this pkg-config file? jdk=@JDK@ jre=@JRE@ lib_arch=@JRE@/lib/@ARCH@ Name: java-1.8.0-openjdk Description: OpenJDK 8 Version: @VERSION@ Cflags: -I${jdk}/include -I${jdk}/include/linux Libs: -L${lib_arch} -L${lib_arch}/@VM@ -ljvm -ljava When built, it will look something like this (on x86_64): jdk=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.x86_64 jre=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.x86_64/jre lib_arch=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.5.x86_64/jre/lib/amd64 Name: java-1.8.0-openjdk Description: OpenJDK 8 Version: 1.8.0.5 Cflags: -I${jdk}/include -I${jdk}/include/linux Libs: -L${lib_arch} -L${lib_arch}/server -ljvm -ljava Are there any additional features needed? If this looks okay, I will send it upstream for further discussion.
That looks great.
I sent the pkg-config file upstream. Then I talked to Mikolaj who pointed me to this: https://bugzilla.redhat.com/show_bug.cgi?id=449456#c5 Basically, it's wrong for fedora packages to link against a specific JVM. We use alternatives and JAVA_HOME to allow users to select the right VM at runtime. Linking directly against a VM runs against this. Individual programs needs to be fixed to use dlopen() on the appropriate JVM and use that. I think this bug should be closed as WONTFIX.
(In reply to Omair Majid from comment #27) > I sent the pkg-config file upstream. > > Then I talked to Mikolaj who pointed me to this: > https://bugzilla.redhat.com/show_bug.cgi?id=449456#c5 > > Basically, it's wrong for fedora packages to link against a specific JVM. We > use alternatives Alternatives control files. pkg-config file is a file. > and JAVA_HOME to allow users to select the right VM at > runtime. Indeed? $ type -a java java je /bin/java java je /usr/bin/java $ readlink --canonicalize /usr/bin/java /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre/bin/java $ cat /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre/bin/java #!/bin/bash if [ -e /usr/lib64/libabrt-java-connector.so ] ; then exec -a java /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre-abrt/bin/java -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on "$@" else exec -a java /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre-abrt/bin/java "$@" fi $ file /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre-abrt/bin/java /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.5.0.1.fc20.x86_64/jre-abrt/bin/java: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=848e939f06a059e6b1b00be447c91d0a0effabbb, stripped Where exactly is JAVA_HOME environment variable used when launching java? I cannot see that. > Individual programs needs to be fixed to use dlopen() on the appropriate JVM > and use that. > Which still leaves the burden of locating the shared library location on the application. If pkg-config is not suitable solution, another locator should be provided. All the bugs are about off-loading this tedious and always broken application-side implementations to one central place. Preferably to the JDK.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
*** This bug has been marked as a duplicate of bug 449456 ***