Bug 42409 - org.eclipse.jdt.internal.compiler.batch.GCCMain not found
Summary: org.eclipse.jdt.internal.compiler.batch.GCCMain not found
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2009-12-17 17:54 UTC by John Poole
Modified: 2010-03-20 00:09 UTC (History)
2 users (show)

See Also:
Host: armv5tel-unknown-linux-gnueabi
Target: armv5tel-unknown-linux-gnueabi
Build: armv5tel-unknown-linux-gnueabi
Known to work:
Known to fail:
Last reconfirmed:

output under normal circumstances (3.62 KB, text/plain)
2010-01-03 18:21 UTC, John Poole
work-around output (4.11 KB, text/plain)
2010-01-03 18:23 UTC, John Poole

Note You need to log in before you can comment on or make changes to this bug.
Description John Poole 2009-12-17 17:54:37 UTC
(This Bug follows 4205 which is not marked FIXED)

On armv5tel-unknown-linux-gnueabi I compiled gcj plus .../contrib/download_ecj.

Last Changed Rev: 155206                                                        
Last Changed Date: 2009-12-13 21:06:50 -0800 (Sun, 13 Dec 2009)           

installed with "DESTDIR=/usr/local/gcj"
set LD_LIBRARY_PATH=/usr/local/gcj/usr/local/lib

plug bin # ./gcj -v -I /usr/local/gcj/usr/local/share/java/libgcj-4.5.0.jar /var

Target: armv5tel-unknown-linux-gnueabi                                          
Configured with: ../trunk/configure --enable-languages=java : (reconfigured) ../
trunk/configure --enable-languages=java                                         
Thread model: posix                                                             
gcc version 4.5.0 20091214 (experimental) (GCC)                                 
COLLECT_GCC_OPTIONS='-fsaw-java-file' '-v' '-fbootclasspath=/usr/local/gcj/usr/l
ocal/share/java/libgcj-4.5.0.jar:./:/usr/local/share/java/libgcj-4.5.0.jar' '-g1
' '-shared-libgcc'                                                              
0/ecj1 /var/work/gcj/HelloWorld.java -g1 -fbootclasspath=/usr/local/gcj/usr/loca
l/share/java/libgcj-4.5.0.jar:./:/usr/local/share/java/libgcj-4.5.0.jar -g1 -fso
urce=1.5 -ftarget=1.5 -fzip-dependency /tmp/ccEAvqtm.zip -fzip-target /tmp/ccgLw
Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.jdt.inter
   at gnu.java.lang.MainThread.run(MainThread.java:100)                         
Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.compiler.b
atch.GCCMain not found in gnu.gcj.runtime.SystemClassLoader{urls=[], 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)                          
plug bin # 

Here's the test code:

    plug bin # cat /var/work/gcj/HelloWorld.java                                    
    class HelloWorld {                                                              
        public static void main(String args[]){                                     
            System.out.println("Hello World!");                                     
    plug bin #     

I really feel badly having to come to you with my struggling; however, I have a good deal of experience with Perl and some Java and find myself gated by what members of this team think trivial.  Please keep in mind when someone comes to try installing the gcc compiler and getting it to run, they do not have the experience and day-to-day exposure you have, so something simple as an incorrect path can be confounding. 

I'm not sure which class is missing (or not pointed to with the class path) from the above output.
Comment 1 John Poole 2009-12-24 16:23:11 UTC
I learned from http://gcc.gnu.org/ml/java/2008-08/msg00031.html (Andrew Haley) how to invoke the test suite:
   make check-target-libjava

Here are my results:
make check-target-libjava
[assorted make executions]
WARNING: Couldn't find the global config file.
Test Run By root on Thu Dec 24 12:21:08 2009
Native configuration is armv5tel-unknown-linux-gnueabi

                === libjava tests ===

Schedule of variations:

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /mnt/seagate2/download/gnu/trunk/libjava/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.cni/cni.exp ...
Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jar/jar.exp ...
Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jni/jni.exp ...
FAIL: calls execution - gij test
FAIL: findclass2 run
Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jvmti/jvmti-interp.exp ...
LD_LIBRARY_PATH=. /mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/./libjava/gij -cp /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jvmti/interp/getargssize.jar -agentlib:dummyagent getargssize
LD_LIBRARY_PATH=. /mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/./libjava/gij -cp /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jvmti/interp/getlocalvartable.jar -agentlib:dummyagent getlocalvartable
LD_LIBRARY_PATH=. /mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/./libjava/gij -cp /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jvmti/interp/getstacktrace.jar -agentlib:dummyagent getstacktrace
Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jvmti/jvmti.exp ...
Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.lang/lang.exp ...
FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 -findirect-dispatch execution - source compiled test
FAIL: Throw_2 -O3 execution - source compiled test
FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test
Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.loader/loader.exp ...
Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.mauve/mauve.exp ...
Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.special/special.exp ...
Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.verify/verify.exp ...

                === libjava Summary ===

# of expected passes            2561
# of unexpected failures        6
# of untested testcases         6
make[3]: *** [check-DEJAGNU] Error 1
make[3]: Leaving directory `/mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/libjava/testsuite'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/libjava/testsuite'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/libjava'
make: *** [check-target-libjava] Error 2
plug build #

The above looks very encouraging which suggests that my only problem of trying to compile, as set forth in this bug, is a configuration issue.  The test suite appears to be able to configure everything it needs from the environment, whereas the "install" environment does not.  I do not know if the six unexpected failures will preclude me from compiling.  Is there a way to get more detail on the failure results?  Is there anything I can do to help shed more light on whatever is causing the failures?

Lastly, does anyone have a suggestion on what I need to include to overcome the "org.eclipse.jdt.internal.compiler.batch.GCCMain" class not found error?
Comment 2 John Poole 2010-01-03 18:21:20 UTC
Created attachment 19454 [details]
output under normal circumstances

In this output, the compiler incorrectly looks for the ecj.jar under /usr/share/java (on my machine, there was no "java" directory under /usr/share), when it should have used the path /usr/local/gcj/usr/share/java where the ecj.jar file and other jar files had been properly placed.
Comment 3 John Poole 2010-01-03 18:23:32 UTC
Created attachment 19456 [details]
work-around output

To overcome the misdirected path, I created a "java" directory under /usr/share and copied the /usr/local/gcj/usr/share/java files to /usr/share/java.  I then successfully ran my command and the output is attached hereto.
Comment 4 John Poole 2010-01-03 18:30:23 UTC
I think I found the problem: 

the compiler is using an incorrect path, e.g. "/usr/share/java", to find the ecj.jar file and the other jar files,   libgcj-4.5.0.jar  libgcj-tools-4.5.0.jar, when it should have used "/usr/local/gcj/usr/share/java".
See line 172 in the attachment gcj_fails-looking_for_ecj_in_wrong_path.txt   	

Recall, I had installed using the DESTDIR parameter:
  make DESTDIR=/usr/local/gcj install
in order not to trash my Gentoo GCC built for my ARMv5t platform.

My work-around was to copy the three jar files under the /usr/local/gcj/usr/share/java directory (where make install had placed them) to /usr/share/java.

My work-around run is attached (gcj_ecj_moved.txt) to this bug.
Comment 5 John Poole 2010-01-03 18:43:09 UTC
Here's my configuration log:

plug build # pwd
plug build # head config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ ../trunk/configure --enable-languages=java

## --------- ##
## Platform. ##
plug build # 
Comment 6 Jakub Jelinek 2010-01-03 18:55:49 UTC
That's just a misunderstanding what DESTDIR is.  DESTDIR just says a directory where the / dir of installed files starts.  It is used when you e.g. want to install everything into a temporary directory to package it up later (e.g. using tar, cpio, rpm, ...).  If /usr/local/gcj/usr/* is where you want gcc to finally reside, you shouldn't use DESTDIR, but instead configure with --prefix /usr/local/gcj/usr.
Comment 7 John Poole 2010-01-04 01:51:03 UTC
Thank you.

I've updated trunk to Revision: 155601.  Wiped out build and am running make (it will take a few days).  I'll update with my results.
Comment 8 Ramana Radhakrishnan 2010-01-04 11:32:57 UTC
Waiting for feedback on this one as per Comment #7.
Comment 9 Jakub Jelinek 2010-01-04 14:20:55 UTC
BTW, DESTDIR is documented e.g. in automake.info quite well.
Comment 10 John Poole 2010-01-05 02:31:42 UTC
http://gcc.gnu.org/install/finalinstall.html has:
We strongly recommend to install into a target directory where there is no previous version of GCC present.
Installation into a temporary staging area or into a chroot jail can be achieved with the command

     make DESTDIR=path-to-rootdir install

where path-to-rootdir is the absolute path of a directory relative to which all installation paths will be interpreted. Note that the directory specified by DESTDIR need not exist yet; it will be created if necessary. 
I think those very words caused me to think what I did was a correct way of isolating the compiler without affecting my existing one.

"make" has finished (about 21 hours) and I ran:
  make check-target-libjava
which produced:
                === libjava Summary ===

# of expected passes            2561
# of unexpected failures        6
# of untested testcases         6

Question:  In light of the documentation quoted above, if I do not use the DESTDIR, then to install, should I simply run:

  make install

and my previous use of --prefix=/usr/local/gcj will cause everything to go under /usr/local/gcj and not affect my existing gcc?  I'm really nervous that running make install will cause it to supplant my existing GCC.  I also want to make sure there is not an additional parameter that should be provided to assure isolation of this installation.
Comment 11 John Poole 2010-01-05 02:34:57 UTC
For the record:
plug build # ls -la config.log
-rw-r--r-- 1 root root 36708 2010-01-03 17:37 config.log
plug build # head config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ ../trunk/configure --enable-languages=java --prefix=/usr/local/gcj

## --------- ##
## Platform. ##
plug build #
Comment 12 John Poole 2010-01-07 14:26:33 UTC

There were no further responses to my question posed in Comment #10; so I proceeded nonetheless.
I deleted /usr/local/gcj and recreated the directory /usr/local/gcj so as to purge any hand-added files from previous attempts.  Then 
from the build directory, /d1/seagate2/download/gnu/build, I ran:

make install

Then I moved to the target install directory, /usr/local/gcj, and from there executed:
 export LD_LIBRARY_PATH=/usr/local/gcj/lib
 bin/gcj -c /var/work/gcj/HelloWorld.java
and the file HellowWorld.o was created.

I'm not sure what the protocol for this Bug system is, this Bug is currently marked WAITING; I'm changing status to NEW in case that triggers an alert for someone of knowledge to act.  Please take a look at comment #10, it may be that documentation needs to be revised.

Thank you for everyone's help.
Comment 13 Ramana Radhakrishnan 2010-03-20 00:09:58 UTC
I think the documentation is adequate in the sense that it is for installation into a "staging area" rather than the final install area. Notice also the use of installing this into a chroot.