From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.5)
Description of problem:
Version-Release number of selected component (if applicable):
java-1.4.2-gcj-compat-126.96.36.199-21jpp with gcc-java-3.4.3-11
Steps to Reproduce:
Try to execute javacc-3.2-2jpp from the JPackage project. It will
[mike@imp ~]$ javacc
Exception in thread "main" java.lang.NoClassDefFoundError: error:
at gnu.gcj.runtime.FirstThread.run() (/usr/lib/libgcj.so.5.0.0)
at _Jv_ThreadRun(java.lang.Thread) (/usr/lib/libgcj.so.5.0.0)
at _Jv_RunMain(java.lang.Class, byte const, int, byte const,
I can't reproduce this on x86. What does "which gcj" print?
[mike@imp ~]$ which gcj
[mike@imp ~]$ which gij
[mike@imp ~]$ which java
[mike@imp ~]$ ls -l /usr/bin/java
lrwxr-xr-x 1 root root 22 Jul 29 13:21 /usr/bin/java ->
[mike@imp ~]$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 35 Dec 12 13:35 /etc/alternatives/java ->
I suspect this is a gcj/gij bug on powerpc. Try running javacc with
Yes, you seem to be correct. Ant no longer works either. I'm not
sure when this broke -- I track Raw Hide pretty closely -- but it did
work before. I haven't been using Java for the last month or so.
I can't reproduce this on my ppc machine. Can you post the relevant
lines in your yum.conf file so that I'm sure I've got the right
I should be tracking Raw Hide only. I installed the javacc RPM from
JPackage by hand.
I just tried reinstalling Raw Hide's gcc-java-3.4.3-11.ppc.rpm and
java-1.4.2-gcj-compat-188.8.131.52-21jpp.noarch.rpm by hand but that did
name=Fedora Core $releasever - Development Tree
Nope, still can't reproduce this. I'm on a ppc64 machine; what does
uname -a report for you?
[mike@imp ~]$ uname -a
Linux imp.flyn.org 2.6.9-1.1021_FC4 #1 Wed Dec 8 18:45:11 EST 2004 ppc
ppc ppc GNU/Linux
My machine is a G4 iBook.
It looks like installing
java-1.4.2-gcj-compat-devel-184.108.40.206-21jpp.noarch.rpm from Raw Hide
fixes this. I didn't have this RPM installed when I reported this bug
but I just installed it (I DID have ava-1.4.2-gcj-compat installed,
though). Now javacc and ant work.
Should java-1.4.2-gcj-compat-devel be required to execute Java
bytecode? If so, why does the ant RPM not require it the package?
Both java-1.4.2-gcj-compat and -devel install an identical program
[mike@imp src]$ rpm -ql java-1.4.2-gcj-compat | grep java$
[mike@imp src]$ rpm -ql java-1.4.2-gcj-compat-devel | grep java$
[mike@imp src]$ diff /usr/lib/jvm/java-1.4.2-gcj-220.127.116.11/jre/bin/java
Ant seems to execute using the one installed by the -devel package:
[mike@imp src]$ ant
exec "/usr/lib/jvm/java/bin/java" -classpath
org.apache.tools.ant.launch.Launcher -lib ""
Ah, OK. The -devel package contains the javac compiler. Ant
BuildRequires java-devel, but doesn't Require it. It should though.
Can you file a separate bug for this?
And yes, two java files are installed, one by the base package and one
by the -devel package. This is how proprietary SDKs are laid out, so
we're just following them.
Closing this report.
This still does not seem right. Granted, ant is probably going to
need the -devel package to build programs. But it shouldn't need it
to simply execute, right? I'm I wrong to think that only a JRE (aka
java-1.4.2-gcj-compat) is needed for this?
After I did some experimentation, I found that simply creating the
empty directory /usr/lib/jvm-exports/java (which is actually a link
installed by the -devel package) allows ant to execute without the
-devel package installed. So I think that java-1.4.2-gcj-compat
should install this directory instead of -devel. See this error:
[mike@imp java-1.4.2-gcj-18.104.22.168]$ ant
exec "/usr/bin/java" -classpath "/usr/bin/build-classpath: error:
JVM_LIBDIR /usr/lib/jvm-exports/java does not exist or is not a
directory:/usr/bin/build-classpath: error: JVM_LIBDIR
/usr/lib/jvm-exports/java does not exist or is not a
org.apache.tools.ant.launch.Launcher -lib ""
Exception in thread "main" java.lang.NoClassDefFoundError:
Javacc behaves the same.
The wierd thing is that this link does not contain anything when it is
installed by -devel:
[mike@imp ~]$ ls -l /usr/lib/jvm-exports/java
lrwxrwxrwx 1 root root 34 Jan 5 18:45 /usr/lib/jvm-exports/java ->
[mike@imp ~]$ ls -l /etc/alternatives/java_sdk_exports
lrwxrwxrwx 1 root root 35 Jan 5 18:45
/etc/alternatives/java_sdk_exports -> /usr/lib/jvm-exports/java-1.4.2-gcj
[mike@imp ~]$ ls -l /usr/lib/jvm-exports/java-1.4.2-gcj
lrwxrwxrwx 1 root root 22 Jan 5 18:44
/usr/lib/jvm-exports/java-1.4.2-gcj -> java-1.4.2-gcj-22.214.171.124
[mike@imp ~]$ ls -l /usr/lib/jvm-exports/java-1.4.2-gcj-126.96.36.199
On a semi-related note, why is ecj used by
java-1.4.2-gcj-compat-devel? Is ecj more complete than gcj?
Ant appears to require the -devel package to be installed, since it
includes ecj.jar on the classpath. Where does this ecj.jar include
How is build-classpath being run? Maybe there's a bug there in that
it assumes a JVM -devel package is installed. Instead of a set of
jars, the classpath string contains build-classpath's error messages.
We use ecj for javac because it is superior to gcj -C. It is faster,
more correct and most importantly for this application, more
command-line compatible with Sun's javac.
Not a gcj bug, AFAICS.
This is a bug in jpackage-utils; it assumes that JAVA_HOME is
/usr/lib/jvm/java. But that symlink is installed by the -devel
package. I'm working on a fix.
The problem was that jpackage-utils wouldn't fall back to look for
$JVM_ROOT/jre when $JVM_ROOT/java didn't exist. Nicolas Mailhot wrote
this patch, which fixes the issue:
--- java-functions.orig 2005-01-14 23:12:24.000000000 +0100
+++ java-functions 2005-01-14 23:17:10.000000000 +0100
@@ -20,8 +20,14 @@
+# Read user configuration file if it exists
+[ -f ~/.java/java.conf ] && . ~/.java/java.conf
[ ! -z "$_JAVA_HOME" -a -d "$_JAVA_HOME" ] && JAVA_HOME="$_JAVA_HOME"
+[ -z "$JAVA_HOME" -a -d "$JVM_ROOT/jre" ] && JAVA_HOME="$JVM_ROOT/jre"
+[ -z "$JAVA_HOME" -a -d "$JVM_ROOT/java" ] && JAVA_HOME="$JVM_ROOT/java"
# Set the java virtual machine
# use $JAVA_HOME if defined
This patch is included in jpackage-utils-1.6.2-1jpp_2rh which should
hit rawhide soon. Can you retest and close this bug if it works?
Okay. Javacc will now execute without java-1.4.2-gcj-compat-devel