Bug 458921
Summary: | eclipse-ecj-3.4.0 doesn't work | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jakub Jelinek <jakub> |
Component: | eclipse | Assignee: | Andrew Haley <aph> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | medium | ||
Version: | 10 | CC: | oliver, overholt, poelstra, tcallawa, tromey |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-02-13 20:46:43 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
Jakub Jelinek
2008-08-13 08:15:42 UTC
Tom, since you did GCCMain and updated for 3.4.0, any ideas here? FWIW, running javac with ecj as my alternative works for me, so it's probably something wrong with GCCMain. Running your command directly, Jakub, I get: gij -cp /usr/share/java/eclipse-ecj.jar \ org.eclipse.jdt.internal.compiler.batch.GCCMain Test.java Missing message: gcc.noClasspath in: org.eclipse.jdt.internal.compiler.batch.messages It looks like gcc.properties isn't being parsed properly but since it's trying to print the noClasspath message, I suspect something else is wrong. In the ecj.jar I built here (from rhug), gcc.properties is merged into org/eclipse/jdt/internal/compiler/batch/messages.properties So, look in your jar for this file. Does it have the "gcc." messages? I think the messages have to be in this file due to how property files are found at runtime. With my .jar I see the same failure that Jakub sees :( I will look at this. Andrew -- I fixed a bug in GCCMain and checked it into the rhug repository. Can you try it out? It fixes the problem for me. (In reply to comment #3) > Andrew -- I fixed a bug in GCCMain and checked it into the rhug > repository. Can you try it out? > It fixes the problem for me. I pushed a build to koji with this fix: http://koji.fedoraproject.org/koji/taskinfo?taskID=776237 And I'm an idiot. I fixed the zxf -> jxf and now it's building again: http://koji.fedoraproject.org/koji/taskinfo?taskID=776291 Unfortunately that only helped partially. Clearly ecj1 now does something, but isn't able to find some java sources: See e.g. http://koji.fedoraproject.org/koji/getfile?taskID=777080&name=build.log The first error reported there is: java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:71) at org.eclipse.jdt.internal.compiler.ReadManager.run(ReadManager.java:160) at java.lang.Thread.run(libgcj.so.9) java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(CompilationUnit.java:71) at org.eclipse.jdt.internal.compiler.ReadManager.run(ReadManager.java:160) at java.lang.Thread.run(libgcj.so.9) make[4]: *** [compile-classes] Error 1 which means ecj1 died before compiling classes. Note redhat/gcc-4_3-branch doesn't ship with any *.class/*.jar files and instead is configured with --enable-java-maintainer-mode and with ecj1 in PATH. Is there any way you could give me a small zip which I could use to reproduce this issue? I can just do a mock build of gcc on ppc64 if that will be sufficient (it might take a while, but ...). Andrew Haley is investigating this. And I believe he'll comment here with "I need a reproducer!" :) Fixed in gcc trunk by http://gcc.gnu.org/ml/java-patches/2008-q3/msg00046.html Lifting F10Blocker, as it looks like this is a gcc bug (with a fix!). Should we close this? This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |