Bug 152256 - Can't build ant SRPM
Can't build ant SRPM
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Gary Benson
:
Depends On:
Blocks: 132524
  Show dependency treegraph
 
Reported: 2005-03-26 16:19 EST by Anthony Green
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-23 05:24:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Build log. (35.79 KB, text/plain)
2005-03-26 16:20 EST, Anthony Green
no flags Details
jcf-dump of the class (2.18 KB, text/plain)
2005-03-30 05:40 EST, Gary Benson
no flags Details

  None (edit)
Description Anthony Green 2005-03-26 16:19:45 EST
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 16:20:25 EST
Created attachment 112365 [details]
Build log.
Comment 2 Gary Benson 2005-03-29 12:12:57 EST
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 05:40:46 EST
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 10:47:14 EST
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 11:03:06 EST
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 11:26:29 EST
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 11:53:56 EST
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 11:55:08 EST
That should be type l, of course.
Comment 9 Anthony Green 2005-03-31 12:09:56 EST
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 17:12:11 EDT
I'm able to build ant now that Andrew has made changes to how Eclipes is packaged.

Comment 11 Gary Benson 2005-04-06 07:58:34 EDT
Sweet
Comment 12 Gary Benson 2005-04-13 12:49:54 EDT
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 14:49:01 EDT
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-13 22:41:19 EDT
(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 07:22:48 EDT
Has anyone tried this without optimization?
Comment 16 Anthony Green 2005-04-16 15:30:14 EDT
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 07:01:31 EDT
Andrew, Anthony, can one of you please send me the patch?
Comment 18 Thomas Fitzsimmons 2005-05-12 16:48:00 EDT
Can this be closed now?
Comment 19 Gary Benson 2005-05-23 05:24:40 EDT
Yes, sorry.  It's worked since gcc-java-4.0.0-0.43

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