From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0
Description of problem:
I'm getting an IncompatibleClassChangeError.
This is with gccj-java-4.0.0-0.35 and eclipse-ecj-3.1.0_fc-0.M5.14.
I'll upload the build log.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Try to build ant SRPM
Created attachment 112365 [details]
Hmmm, I can't reproduce this on my box. Could you jcf-dump the offending class
for me please? It's
Created attachment 112448 [details]
jcf-dump of the class
Here's what jcf-dump says of the class that beehive builds.
Yesterday we determined that this was triggered by Eclipse starting to use the
system classpath.db. I think gbenson has some work stalled on this. Could we
maybe set Eclipse up to use its own db for now? Even better would be for it to
use the system's ant instead of its own version.
There's still a bug somewhere - these are just work-around ideas.
I have no problem reverting Eclipse to use its own db but I already symlink out
all of the ant stuff that I can. This includes ant.jar.
Then why are we bothering to build native ant jars for Eclipse? The
classmap.db should simply refer to the native ones we build for ant itself
(which we can't do until the problem is solved, or we stop building the native
ant in Eclipse).
That's an artifact of the way we're building all the native stuff for Eclipse.
Since we're symlinking out to the jars in /usr/share/java, our "find jars and
natively-compile them" loop finds the ones that are symlinks and compiles those
as well ... I guess I should implement an find -name \*.jar -and -not -type s or
something like that. This of course assumes all the packages we're using as
dependencies have native stuff.
That should be type l, of course.
I think this is a great idea for three reasons:
- it will work around the 152256 (this) bug
- it will force us to get moving on natively compiling other packages
- Eclipse will continue working as we nativify everything by interpreting the jars
I'm able to build ant now that Andrew has made changes to how Eclipes is packaged.
I'm reopening this since I'm getting this exact same bug now that I've built
native code stuff for ant (on my local box). There's obviously something wrong
with the native code generation :-/
I was able to reproduce this by building libant.jar.so by hand and adding it to
Then I built the ant SRPM with Sun's JDK, and rebuilt libant.jar.so and
classmap.db. I was able to reproduce the problem exactly with this
configuration. I hope this helps narrow down the problem.
(In reply to comment #12)
> I'm reopening this since I'm getting this exact same bug now that I've built
> native code stuff for ant (on my local box). There's obviously something wrong
> with the native code generation :-/
Bryce is having a look at this now. For the record, the steps to reproduce are
1. install the ant RPM
2. $ gcj -shared -fPIC -findirect-dispatch -Wl,-Bsymbolic -O2 -o
3. $ gcj-dbtool -a /usr/lib/gcj-4.0.0/classmap.db.d/ant.db
4. $ rebuild-gcj-db /usr/lib
5. rebuild the ant SRPM
Has anyone tried this without optimization?
Good news - aph sent me a gcj patch to try and it fixes this problem!
I confirmed that I was able to build the ant SRPM when I had a native ant
installed. I confirmed that gij was using the native code by looking at the
output from lsof.
Andrew - I was also able to build and run a bunch of other code with this patch.
Andrew, Anthony, can one of you please send me the patch?
Can this be closed now?
Yes, sorry. It's worked since gcc-java-4.0.0-0.43