This is the mail archive of the
java-prs@gcc.gnu.org
mailing list for the Java project.
[Bug java/45773] New: gcj fails to compile java
- From: "howarth at nitro dot med.uc.edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: java-prs at gcc dot gnu dot org
- Date: Mon, 27 Sep 2010 20:46:06 +0000
- Subject: [Bug java/45773] New: gcj fails to compile java
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45773
Summary: gcj fails to compile java
Product: gcc
Version: 4.6.0
Status: ASSIGNED
Severity: normal
Priority: P3
Component: java
AssignedTo: aph@gcc.gnu.org
ReportedBy: howarth@nitro.med.uc.edu
CC: aph@redhat.com, aph@gcc.gnu.org,
joseph@codesourcery.com, iains@gcc.gnu.org
Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
Build: x86_64-apple-darwin10
Last reconfirmed 2010-09-27 16:57:09
date:
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
Jack Howarth <howarth at nitro dot med.uc.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |
CC| |joseph at codesourcery dot
| |com
CC| |iains at gcc dot gnu.org
CC| |aph at redhat dot com
Andrew Haley <aph at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aph at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2010.09.27 16:57:09
date| |
AssignedTo|unassigned at gcc dot |aph at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
Current gcc trunk, r164573, patched with...
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01914.html
to solve the darwin bootstrap, fails to compile java files. The simple
testme.java file...
public class testme {
public static void main(String args[]){
System.out.println("Hello");
}
}
fails to compile with...
gcj --main=testme -O testme.java
Exception in thread "main" java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(libgcj.12.dylib)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:/sw/share/java/ecj/ecj.jar,file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.12.dylib)
at java.lang.ClassLoader.loadClass(libgcj.12.dylib)
at java.lang.ClassLoader.loadClass(libgcj.12.dylib)
at gnu.java.lang.MainThread.run(libgcj.12.dylib)
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-09-24 02:56:31 UTC ---
> java.lang.NoClassDefFoundError:
> org.eclipse.jdt.internal.compiler.batch.GCCMain
That means you don't have ecj installed. You can installed it via
contrib/download_ecj and follow the instructions in that file.
--- Comment #2 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-25 02:08:58 UTC ---
ecj.jar is installed in the source directory before configure is executed. This
approach has worked for several gcc releases including gcc 4.5.2. So far the
regression appears as far back as r163970 so the stack boundary fixes at
r163971 are not to blame.
--- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-25 03:21:22 UTC ---
Problem doesn't exist at r162829.
--- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-25 07:05:40 UTC ---
Regression is not present at r163768 but is present at r163770 with r163814
backported to allow libjava to build. Thus the regression is introduced with...
Author: jsm28
Date: Thu Sep 2 11:41:22 2010
New Revision: 163770
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163770
Log:
PR driver/44076
* opts.h (struct cl_option): Add alias_arg, neg_alias_arg and
alias_target fields.
* opt-functions.awk (opt_sanitized_name): Don't handle
finline-limit=, Wlarger-than= and ftemplate-depth= specially.
* optc-gen.awk: Generate alias fields.
* opth-gen.awk: Explicitly give values for OPT_* enum constants.
Don't generate such constants for aliases.
* opts-common.c (generate_canonical_option): New.
(decode_cmdline_option): Handle aliases. Use
generate_canonical_option for known options instead of copying the
input option text.
* doc/options.texi (Alias): Document.
* common.opt (W, Wlarger-than-, aux-info=, finline-limit-,
fstack-check, specs): Mark as aliases.
* gcc.c (driver_handle_option): Canonicalize -L options to joined
arguments.
(driver_handle_option): Don't handle OPT_specs.
* opts.c (common_handle_option): Don't handle options marked as
aliases.
(enable_warning_as_error): Handle aliases.
* stor-layout.c (layout_decl): Use OPT_Wlarger_than_ instead of
OPT_Wlarger_than_eq.
* tree-optimize.c (tree_rest_of_compilation): Use
OPT_Wlarger_than_ instead of OPT_Wlarger_than_eq.
c-family:
* c.opt (Wcomments, Werror-implicit-function-declaration,
ftemplate-depth-, std=c89, std=c9x, std=gnu89, std=gnu9x,
std=iso9899:1990, std=iso9899:1999, std=iso9899:199x): Mark as
aliases.
* c-common.c (option_codes): Use OPT_Wcomment instead of
OPT_Wcomments.
* c-opts.c (warning_as_error_callback, c_common_handle_option):
Don't handle options marked as aliases.
java:
* lang.opt (CLASSPATH, bootclasspath, classpath, encoding,
fCLASSPATH=): Mark as Java options and as aliases.
* jvspec.c (jvgenmain_spec): Don't handle -fCLASSPATH*.
(lang_specific_driver): Don't handle options marked as aliases.
* lang.c (java_handle_option): Don't handle OPT_fCLASSPATH_.
testsuite:
* gcc.dg/cpp/warn-comments-3.c: New. Based on warn-comments-2.c
but using -Werror=comment.
* gcc.dg/cpp/warn-comments.c, gcc.dg/cpp/warn-comments-2.c: Adjust
expected error messages.
--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-25 14:20:13 UTC ---
The libjava testsuite is badly in need of testcase for compiling a java source
file. Currently all of the test gcj tests are done using precompiled class
files and breakage in gcj for compilation of java source files goes unreported
on gcc-testresults.
--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-09-25 17:36:07 UTC ---
The only Java issue I know of with r163770 was fixed in r163814. If the
problem you have was not fixed there you'll need to investigate further.
--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-09-25 17:39:37 UTC ---
That is, exactly what is different about how subprocesses are invoked
before/after those changes?
--- Comment #8 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-26 01:53:53 UTC ---
This problem is also reproducible under x86_64 Fedora 10 Linux with current gcc
trunk using the following steps...
cd gcc
wget -c ftp://sourceware.org/pub/java/ecj-latest.jar
mv ecj-latest.jar ecj.jar
cd ../work
../gcc/configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr
--prefix=/home/howarth/dist --enable-languages=c,c++,java
make -j 8
make install
cd ..
./dist/bin/gcj --main=testme -O testme.java
Exception in thread "main" java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(libgcj.so.9)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.9)
at java.lang.ClassLoader.loadClass(libgcj.so.9)
at java.lang.ClassLoader.loadClass(libgcj.so.9)
at gnu.java.lang.MainThread.run(libgcj.so.9)
--- Comment #9 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-26 02:54:13 UTC ---
(In reply to comment #7)
> That is, exactly what is different about how subprocesses are invoked
> before/after those changes?
I don't see any particular differences in the command generated for ecj1. In
both cases, it is...
/home/howarth/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/ecj1 -v
testme.java -fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar
-fsource=1.5 -ftarget=1.5 -fzip-dependency testme.zip -fzip-target testme.jar
however after r163770, this results in the error...
Exception in thread "main" java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(libgcj.so.9)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.9)
at java.lang.ClassLoader.loadClass(libgcj.so.9)
at java.lang.ClassLoader.loadClass(libgcj.so.9)
at gnu.java.lang.MainThread.run(libgcj.so.9)
whereas before r163770 the commands...
COLLECT_GCC_OPTIONS='-fsaw-java-file' '-v' '-save-temps' '-O'
'-fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/home/howarth/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/jc1 testme.jar
-fsource-filename=testme.java -fhash-synchronization -fno-use-divide-subroutine
-fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -quiet -dumpbase
testme.java -mtune=generic -march=x86-64 -auxbase testme -O -version
-fsaw-java-file
-fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar
-faux-classpath testme.zip -o testme.s
were executed instead.
--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-09-26 14:47:56 UTC ---
On Sun, 26 Sep 2010, howarth at nitro dot med.uc.edu wrote:
> --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-09-24 02:56:31 UTC ---
> --- Comment #2 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-25 02:08:58 UTC ---
> --- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-25 03:21:22 UTC ---
> --- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-25 07:05:40 UTC ---
> --- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-25 14:20:13 UTC ---
> --- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-09-25 17:36:07 UTC ---
> --- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-09-25 17:39:37 UTC ---
> --- Comment #8 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-26 01:53:53 UTC ---
> --- Comment #9 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-26 02:54:13 UTC ---
The messages from this bug are becoming less and less useful as each one
repeats all of the previous comments and none are actually being CC:ed to
me.
> I don't see any particular differences in the command generated for ecj1. In
> both cases, it is...
>
> /home/howarth/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/ecj1 -v
> testme.java -fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar
> -fsource=1.5 -ftarget=1.5 -fzip-dependency testme.zip -fzip-target testme.jar
>
> however after r163770, this results in the error...
So, if you build and install a version that works for you, then run this
command manually, it works, but if you build and install a version that
doesn't work for you, and run the same ecj1 command, that ecj1 command
fails? So there is some issue with ecj1 being miscompiled? (I don't
think ecj1 contains any code affected by my patch at all.)
--- Comment #11 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-26 15:17:23 UTC ---
(In reply to comment #10)
> So, if you build and install a version that works for you, then run this
> command manually, it works, but if you build and install a version that
> doesn't work for you, and run the same ecj1 command, that ecj1 command
> fails? So there is some issue with ecj1 being miscompiled? (I don't
> think ecj1 contains any code affected by my patch at all.)
No, it is very simple. If you build gcc with ecj.jar in the source directory
and attempt to compile java source files using gcj (not using precompiled
classes as the test suite does), the gcj compiler crashes before it can emit
the subprocess for ecj1. This issue appears with the commit of r163770 and is
still present in current gcc trunk. It did not exist before r163770. You should
be able to very easily reproduce this bug under linux.
--- Comment #12 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-26 15:48:33 UTC ---
FYI, the original patch which added support for building against ecj.jar can be
found here...
http://gcc.gnu.org/ml/java-patches/2006-q4/msg00061.html
--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-09-26 17:40:16 UTC ---
On Sun, 26 Sep 2010, howarth at nitro dot med.uc.edu wrote:
> --- Comment #11 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-26 15:17:23 UTC ---
> (In reply to comment #10)
>
> > So, if you build and install a version that works for you, then run this
> > command manually, it works, but if you build and install a version that
> > doesn't work for you, and run the same ecj1 command, that ecj1 command
> > fails? So there is some issue with ecj1 being miscompiled? (I don't
> > think ecj1 contains any code affected by my patch at all.)
>
> No, it is very simple. If you build gcc with ecj.jar in the source directory
> and attempt to compile java source files using gcj (not using precompiled
> classes as the test suite does), the gcj compiler crashes before it can emit
> the subprocess for ecj1. This issue appears with the commit of r163770 and is
This doesn't make sense to me. You previously quoted an exception which
appeared to come from the ecj1 process (or at least, from some program
written in Java). Please clarify: does ecj1 run or not in each case?
Does it give an error or not in each case? What if you swap ecj1 binaries
from before/after the change, given a driver from before the change?
What if you swap driver (gcj) binaries from before/after the change, given
ecj1 from before the change?
--- Comment #14 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-26 18:24:40 UTC ---
The crash under x86_64 linux....
./dist/bin/gcj -v --main=testme -O testme.java
Using built-in specs.
Reading specs from
/home/howarth/dist/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=./dist/bin/gcj
COLLECT_LTO_WRAPPER=/home/howarth/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --with-gmp=/usr --with-mpfr=/usr
--with-mpc=/usr --prefix=/home/howarth/dist --enable-languages=c,c++,java
Thread model: posix
gcc version 4.6.0 20100926 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-fsaw-java-file' '-v' '-O'
'-fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/home/howarth/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/ecj1 testme.java
-fbootclasspath=./:/home/howarth/dist/share/java/libgcj-4.6.0.jar -fsource=1.5
-ftarget=1.5 -fzip-dependency /tmp/ccBcVSIa.zip -fzip-target /tmp/ccMm0Hhb.jar
Exception in thread "main" java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(MainThread.java:100)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(URLClassLoader.java:531)
at java.lang.ClassLoader.loadClass(ClassLoader.java:452)
at java.lang.ClassLoader.loadClass(ClassLoader.java:387)
at gnu.java.lang.MainThread.run(MainThread.java:96)
and the crash under x86_64-apple-darwin10...
gcj -v --main=testme -O testme.java
Using built-in specs.
Reading specs from
/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=gcj
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc-4.6-20100925/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-checking=yes
Thread model: posix
gcc version 4.6.0 20100925 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-fsaw-java-file' '-mmacosx-version-min=10.6.5' '-v' '-O'
'-fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.6/share/java/libgcj-4.6.0.jar'
'-shared-libgcc' '-mtune=generic'
/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/ecj1 testme.java
-fbootclasspath=/sw/share/java/ecj/ecj.jar:./:/sw/lib/gcc4.6/share/java/libgcj-4.6.0.jar
-fsource=1.5 -ftarget=1.5 -fzip-dependency
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccIICjFy.zip -fzip-target
/var/folders/1C/1CdoNxmNFHyOIjNBLNuJh++++TM/-Tmp-//ccDWYcg6.jar
Exception in thread "main" java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(libgcj.12.dylib)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:/sw/share/java/ecj/ecj.jar,file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.12.dylib)
at java.lang.ClassLoader.loadClass(libgcj.12.dylib)
at java.lang.ClassLoader.loadClass(libgcj.12.dylib)
at gnu.java.lang.MainThread.run(libgcj.12.dylib)
are both in ecj1 and effectively identical.
--- Comment #15 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-26 18:28:19 UTC ---
Also note comment 2. The regression caused by r163770 looks very much like what
one would get from not having ecj.jar installed (or in this case not being able
to fine the classes from ecj.jar).
--- Comment #16 from Andrew Haley <aph at gcc dot gnu.org> 2010-09-27 15:28:07 UTC ---
The problem is due to gcj's arg processing being broken.
This test case:
public class Test
{
public static void main(String[] args)
{
System.out.println(System.getProperty("java.class.path"));
}
}
$ javac Test.java
$ ~/gcc/trunk/install/bin/gcj Test.class --main=Test
-Djava.class.path=/home/aph/gcc/trunk/install/share/java/ecj.jar
$ $ LD_LIBRARY_PATH=~/gcc/trunk/install/lib64/ ./a.out
.
Should be:
$ /usr/bin/gcj Test.java --main=Test
-Djava.class.path=/home/aph/gcc/trunk/install/share/java/ecj.jar
$ ./a.out
/home/aph/gcc/trunk/install/share/java/ecj.jar
So, -D arguments are no longer being processed after the arg processing
changes.
--- Comment #17 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-09-27 16:55:35 UTC ---
On Mon, 27 Sep 2010, aph at gcc dot gnu.org wrote:
> The problem is due to gcj's arg processing being broken.
>
> This test case:
>
> public class Test
> {
> public static void main(String[] args)
> {
> System.out.println(System.getProperty("java.class.path"));
> }
> }
>
> $ javac Test.java
> $ ~/gcc/trunk/install/bin/gcj Test.class --main=Test
> -Djava.class.path=/home/aph/gcc/trunk/install/share/java/ecj.jar
> $ $ LD_LIBRARY_PATH=~/gcc/trunk/install/lib64/ ./a.out
> .
>
> Should be:
>
> $ /usr/bin/gcj Test.java --main=Test
> -Djava.class.path=/home/aph/gcc/trunk/install/share/java/ecj.jar
> $ ./a.out
> /home/aph/gcc/trunk/install/share/java/ecj.jar
>
> So, -D arguments are no longer being processed after the arg processing
> changes.
Thanks. Since ecj1 doesn't appear to receive -D options I think the most
likely possibility is that HJ's patch to make jvgenmain handle -D options
with separate argument was not in fact a complete fix for this issue. Try
this untested patch or something similar.
Index: jvgenmain.c
===================================================================
--- jvgenmain.c (revision 164647)
+++ jvgenmain.c (working copy)
@@ -124,7 +124,10 @@
{
const char *p;
fprintf (stream, " \"");
- for (p = &argv[i][2]; *p; ++p)
+ p = &argv[i][2];
+ if (*p == '\0')
+ p = &argv[++i][0];
+ for (; *p; ++p)
{
if (! ISPRINT (*p))
fprintf (stream, "\\%o", *p);
--- Comment #18 from Andrew Haley <aph at gcc dot gnu.org> 2010-09-27 16:56:12 UTC ---
Created attachment 21896
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21896
It's a patch.
--- Comment #19 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-09-27 20:45:45 UTC ---
(In reply to comment #18)
> Created attachment 21896 [details]
> It's a patch.
This patch solves both test cases under x86_64 Fedora 10 linux (although a
complete bootstrap was required).