Created attachment 313409 [details] Screengrab of crash message on startup Description of problem: I have just installed the Fedora Eclipse group on a new F9 system upgraded to Rawhide. Eclipse crashes on startup. Version-Release number of selected component (if applicable): eclipse-rcp-3.3.2-12.fc9.x86_64 How reproducible: 3 times Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please post more information. How are you executing it could you post anything that is in the console if you run it from there i.e. [user@localhost ~]$ eclipse
This is a known issue at the moment as we were holding off getting Eclipse 3.4 into rawhide until all of the Eclipse plugins were ready. It's probably because the icu4j symlink is broken due to it upgrading for 3.4 but 3.3.2 being the only thing available. We'll have 3.4 sometime this week. Sorry about this.
Actually, this might be a wider java problem?: java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory It may be that the yum upgrade to rawhide missed something.
OpenJDK was updated in rawhide today. Can you try updating and reproducing this issue?
Am running java-1.6.0-openjdk-1.6.0.0-0.20.b11.fc10.x86_64 and I still have the same problem.
wrt #3 given "java" reporting... java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory I bet that using an explicit path of /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java works as would $(readlink -f `which java`) to expand out the location of java explicitly ? i.e. the problem is most likely that of expansion of $ORIGIN when there are links involved readelf -d $(readlink -f `which java`) | grep RPATH 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli] and is related to the glibc ORIGIN changes that caused the more obvious and fixed bug 457560 If so, then this part at least is probably glibc's issue rather than openjdk's
Re-assigning component.
I can't reproduce this on x86_64 with eclipse 3.3.2 or 3.4. $ java -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) Other similar reports suggest this is no longer a problem after they updated java-1.6.0-openjdk and java-1.6.0-openjdk-devel. Do you have a crash report?
[caolan@Nom builds]$ rpm -q java-1.6.0-openjdk java-1.6.0-openjdk-1.6.0.0-0.20.b11.fc10.x86_64 [caolan@Nom builds]$ rpm -q java-1.6.0-openjdk-devel java-1.6.0-openjdk-devel-1.6.0.0-0.20.b11.fc10.x86_64 [caolan@Nom builds]$ java -version java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory [caolan@Nom builds]$ which java /usr/bin/java [caolan@Nom builds]$ readlink -f `which java` /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java [caolan@Nom builds]$ $(readlink -f `which java`) -version java version "1.6.0_0" OpenJDK Runtime Environment (build 1.6.0_0-b11) OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode) [caolan@Nom builds]$ rpm -q glibc.x86_64 glibc-2.8.90-11.x86_64 [caolan@Nom builds]$ I still suspect that (this can't find libjli.so bit anyway) is some glibc ORIGIN following foo
As per https://bugzilla.redhat.com/show_bug.cgi?id=457849#c6, invoking java does work when the full location is given. I'm running the same versions listed in https://bugzilla.redhat.com/show_bug.cgi?id=457849#c9
(In reply to comment #9) > I still suspect that (this can't find libjli.so bit anyway) is some glibc > ORIGIN following foo I don't see anything wrong. Look at the encoded path: $ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli The binary is /usr/bin/java. But none of /usr/lib/amd64 and /usr/jre exists. My guess is that previously the binary was in a different place (somewhere under /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64) and the path hasn't been adjusted.
I double checked. None of the paths have changed. I can reproduce this problem on my own rawhide machine.
re #11 [caolan@Nom ~]$ which java /usr/bin/java [caolan@Nom ~]$ ls -asl /usr/bin/java 0 lrwxrwxrwx 1 root root 22 2008-01-29 14:49 /usr/bin/java -> /etc/alternatives/java [caolan@Nom ~]$ ls -asl /etc/alternatives/java 0 lrwxrwxrwx 1 root root 46 2008-08-08 17:14 /etc/alternatives/java -> /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java [caolan@Nom ~]$ ls -asl /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java 40 -rwxr-xr-x 1 root root 39584 2008-08-05 20:12 /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java [caolan@Nom ~]$ readelf -d /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java|grep RPATH 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli] [caolan@Nom ~]$ ls -asl /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/../lib/amd64/jli total 28 4 drwxr-xr-x 2 root root 4096 2008-08-09 04:20 . 4 drwxr-xr-x 7 root root 4096 2008-08-08 17:14 .. 20 -rwxr-xr-x 1 root root 18216 2008-08-05 20:12 libjli.so [caolan@Nom ~]$ strace java 2>&1| grep libjli open("/lib64/tls/x86_64/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib64/tls/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib64/x86_64/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib64/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/x86_64/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/tls/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/x86_64/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib64/libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory) writev(2, [{"java"..., 4}, {": "..., 2}, {"error while loading shared librar"..., 36}, {": "..., 2}, {"libjli.so"..., 9}, {": "..., 2}, {"cannot open shared object file"..., 30}, {": "..., 2}, {"No such file or directory"..., 25}, {"\n"..., 1}], 10java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
OK, this is a change in behavior. And a bad one. The kernel doesn't pass up a normalized path name and therefore we shouldn't use it at all. I've reverted the code upstream. Should be fixed with the next rawhide build of glibc.
thank you! Adam- does this fix your problem? Can we close the bug?
*** Bug 460239 has been marked as a duplicate of this bug. ***
Ulrich, could you queue up the updated glibc on Koji? Adam and I cannot confirm that the change works, since there is no updated glibc to test against.
Yes, I can confirm that glibc-2.8.90-12.x86_64 works as it should. java -version gives reasonable answer.
Confirmed that it works here as well (x86_64)
Yes, works for me now.