(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 /work/gcj/HelloWorld.java produces: ... 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' /usr/local/gcj/usr/local/bin/../libexec/gcc/armv5tel-unknown-linux-gnueabi/4.5. 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 7My.jar Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.jdt.inter nal.compiler.batch.GCCMain 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.
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: unix 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?
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.
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.
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.
Here's my configuration log: plug build # pwd /mnt/seagate2/download/gnu/build 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 #
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.
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.
Waiting for feedback on this one as per Comment #7.
BTW, DESTDIR is documented e.g. in automake.info quite well.
http://gcc.gnu.org/install/finalinstall.html has: vvvvv ... 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.
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 #
Success. 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.
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. cheers Ramana