Bug 152256

Summary: Can't build ant SRPM
Product: [Fedora] Fedora Reporter: Anthony Green <green>
Component: gccAssignee: Gary Benson <gbenson>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: aph, mckinlay, overholt, tromey
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-23 09:24:40 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:
Bug Depends On:    
Bug Blocks: 132524    
Attachments:
Description Flags
Build log.
none
jcf-dump of the class none

Description Anthony Green 2005-03-26 21:19:45 UTC
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):
ant-1.6.2-3jpp_2fc

How reproducible:
Always

Steps to Reproduce:
1.Try to build ant SRPM
2.
3.
  

Additional info:

Comment 1 Anthony Green 2005-03-26 21:20:25 UTC
Created attachment 112365 [details]
Build log.

Comment 2 Gary Benson 2005-03-29 17:12:57 UTC
Hmmm, I can't reproduce this on my box.  Could you jcf-dump the offending class
for me please?  It's
apache-ant-1.6.2/build/classes/org/apache/tools/ant/IntrospectionHelper$1.class

Comment 3 Gary Benson 2005-03-30 10:40:46 UTC
Created attachment 112448 [details]
jcf-dump of the class

Here's what jcf-dump says of the class that beehive builds.

Comment 4 Anthony Green 2005-03-31 15:47:14 UTC
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.


Comment 5 Andrew Overholt 2005-03-31 16:03:06 UTC
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.

Comment 6 Anthony Green 2005-03-31 16:26:29 UTC
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).



Comment 7 Andrew Overholt 2005-03-31 16:53:56 UTC
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.

Comment 8 Andrew Overholt 2005-03-31 16:55:08 UTC
That should be type l, of course.

Comment 9 Anthony Green 2005-03-31 17:09:56 UTC
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


Comment 10 Anthony Green 2005-04-05 21:12:11 UTC
I'm able to build ant now that Andrew has made changes to how Eclipes is packaged.



Comment 11 Gary Benson 2005-04-06 11:58:34 UTC
Sweet

Comment 12 Gary Benson 2005-04-13 16:49:54 UTC
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 :-/

Comment 13 Anthony Green 2005-04-13 18:49:01 UTC
I was able to reproduce this by building libant.jar.so by hand and adding it to
my classmap.db.

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.


Comment 14 Anthony Green 2005-04-14 02:41:19 UTC
(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
as follows:

1. install the ant RPM
2. $ gcj -shared -fPIC -findirect-dispatch -Wl,-Bsymbolic -O2 -o
/usr/lib/libant.jar.so /usr/share/java/ant.jar
3. $ gcj-dbtool -a /usr/lib/gcj-4.0.0/classmap.db.d/ant.db
/usr/share/java/ant.jar  /usr/lib/libant.jar.so
4. $ rebuild-gcj-db /usr/lib
5. rebuild the ant SRPM





Comment 15 Andrew Haley 2005-04-14 11:22:48 UTC
Has anyone tried this without optimization?

Comment 16 Anthony Green 2005-04-16 19:30:14 UTC
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.
 Great work!

Comment 17 Gary Benson 2005-04-18 11:01:31 UTC
Andrew, Anthony, can one of you please send me the patch?

Comment 18 Thomas Fitzsimmons 2005-05-12 20:48:00 UTC
Can this be closed now?


Comment 19 Gary Benson 2005-05-23 09:24:40 UTC
Yes, sorry.  It's worked since gcc-java-4.0.0-0.43