Bug 458921 - eclipse-ecj-3.4.0 doesn't work
eclipse-ecj-3.4.0 doesn't work
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
10
All Linux
medium Severity urgent
: ---
: ---
Assigned To: Andrew Haley
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-13 04:15 EDT by Jakub Jelinek
Modified: 2009-02-13 15:46 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-13 15:46:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jakub Jelinek 2008-08-13 04:15:42 EDT
eclipse-ecj-3.4.0-* doesn't work at all.
Even simple gcj -C A.java with any class I've tried doesn't generate any class.
ecj1 can be a binary from gcj, but the same effect can be seen with just
#!/bin/sh
exec gij -cp /usr/share/java/eclipse-ecj.jar \
org.eclipse.jdt.internal.compiler.batch.GCCMain "$@"
The gcj command succeeds, but no A.class appears.  This prevents a new gcc build in rawhide (no *.java is ever compiled into *.class), so it is pretty fatal for me.
Reverting back to eclipse-ecj-3.3.2-12.fc9 fixes this, upgrading again to
eclipse-ecj-3.4.0-18.fc10 or eclipse-ecj-3.4.0-20.fc10 breaks it again.
Comment 1 Andrew Overholt 2008-08-13 09:36:27 EDT
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.
Comment 2 Tom Tromey 2008-08-13 12:49:37 EDT
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.
Comment 3 Tom Tromey 2008-08-13 13:48:14 EDT
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.
Comment 4 Andrew Overholt 2008-08-13 16:33:32 EDT
(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
Comment 5 Andrew Overholt 2008-08-13 16:36:44 EDT
And I'm an idiot.  I fixed the zxf -> jxf and now it's building again:

http://koji.fedoraproject.org/koji/taskinfo?taskID=776291
Comment 6 Jakub Jelinek 2008-08-14 04:43:58 EDT
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.
Comment 7 Andrew Overholt 2008-08-14 09:06:37 EDT
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 ...).
Comment 8 Andrew Overholt 2008-08-21 08:37:58 EDT
Andrew Haley is investigating this.  And I believe he'll comment here with "I need a reproducer!" :)
Comment 9 Andrew Haley 2008-10-24 09:47:53 EDT
Fixed in gcc trunk by http://gcc.gnu.org/ml/java-patches/2008-q3/msg00046.html
Comment 10 Tom "spot" Callaway 2008-10-27 14:49:44 EDT
Lifting F10Blocker, as it looks like this is a gcc bug (with a fix!).
Comment 11 Andrew Overholt 2008-11-07 18:42:42 EST
Should we close this?
Comment 12 Bug Zapper 2008-11-25 21:45:28 EST
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

Note You need to log in before you can comment on or make changes to this bug.