Re: GCCMain not found & test suite errors fatal?

Re: GCCMain not found & test suite errors fatal?

[John Poole]

You wrote:

>>  I suggest you grab ecj.jar and put it in install/share/java.  That
>>  should get you a fully working gcj.


Thank you, Andrew, I had already tried to do so.

Previously I learned the hard way about the ecj.jar issue, so I ran 
the.../contrib/download_ecj script (which downloaded the ecj.jar from 
the predefined site) to install the ecj.jar into the trunk directory, I 
then ran the configuration again so the ecj.jar would be staged into my 
target for "make ... install".

In fact, I do have ecj.jar installed in my target tree: /usr/local/gcj.

I even tried adding it to the include parameter and still get the same 
result. Maybe I'm not using the correct parameter syntax??

plug local # pwd
/usr/local/gcj/usr/local
plug local # find . -name '*ecj*.jar'
./share/java/ecj.jar
plug local # export LD_LIBRARY_PATH=/usr/local/gcj/usr/local/lib
plug local #
plug local # ./bin/gcj  -I./lib/:./share/java/ecj.jar -c 
/var/work/gcj/HelloWorld.java [B
gcj: [B: No such file or directory
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=[], 
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 local #

Re: GCCMain not found & test suite errors fatal?

[Andrew Haley]

On 12/31/2009 05:17 PM, John Poole wrote:
> You wrote:
> 
>>>  I suggest you grab ecj.jar and put it in install/share/java.  That
>>>  should get you a fully working gcj.
> 
> 
> Thank you, Andrew, I had already tried to do so.
> 
> Previously I learned the hard way about the ecj.jar issue, so I ran 
> the.../contrib/download_ecj script (which downloaded the ecj.jar from 
> the predefined site) to install the ecj.jar into the trunk directory, I 
> then ran the configuration again so the ecj.jar would be staged into my 
> target for "make ... install".
> 
> In fact, I do have ecj.jar installed in my target tree: /usr/local/gcj.
> 
> I even tried adding it to the include parameter and still get the same 
> result. Maybe I'm not using the correct parameter syntax??
> 
> plug local # pwd
> /usr/local/gcj/usr/local
> plug local # find . -name '*ecj*.jar'
> ./share/java/ecj.jar
> plug local # export LD_LIBRARY_PATH=/usr/local/gcj/usr/local/lib
> plug local #
> plug local # ./bin/gcj  -I./lib/:./share/java/ecj.jar -c 
> /var/work/gcj/HelloWorld.java [B

You don't want the -I part.

I'd try stracing gcj to find out what's going on

 $ strace -f -etrace=file gcj -c HelloWorld.java

This will tell you where gcj is looking for its jarfiles.  Look for
something like this:

...
547   execve("/home/aph/gcc/trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/ecj1", ["/home/aph/gcc/trunk/install/libe"..., "Hello.java", "-g1", "-fbootclasspath=./:/home/aph/gcc"..., "-g1", "-fsource=1.5", "-ftarget=1.5", "-fzip-dependency", "/tmp/ccXyDB9d.zip", "-fzip-target", "/tmp/ccipPqBc.jar"], [/* 42 vars */]) = 0
...
547   stat("/home/aph/gcc/trunk/install/share/java/ecj.jar", {st_mode=S_IFREG|0644, st_size=1377431, ...}) = 0
547   open("/home/aph/gcc/trunk/install/share/java/ecj.jar", O_RDONLY) = 3
...

Andrew.

Re: GCCMain not found & test suite errors fatal?

[John Poole]

On 1/3/2010 8:28 AM, Andrew Haley wrote:
> On 12/31/2009 05:17 PM, John Poole wrote:
>    
>> You wrote:
>>
>>      
>>>>   I suggest you grab ecj.jar and put it in install/share/java.  That
>>>>   should get you a fully working gcj.
>>>>          
>>
>> Thank you, Andrew, I had already tried to do so.
>>
>> Previously I learned the hard way about the ecj.jar issue, so I ran
>> the.../contrib/download_ecj script (which downloaded the ecj.jar from
>> the predefined site) to install the ecj.jar into the trunk directory, I
>> then ran the configuration again so the ecj.jar would be staged into my
>> target for "make ... install".
>>
>> In fact, I do have ecj.jar installed in my target tree: /usr/local/gcj.
>>
>> I even tried adding it to the include parameter and still get the same
>> result. Maybe I'm not using the correct parameter syntax??
>>
>> plug local # pwd
>> /usr/local/gcj/usr/local
>> plug local # find . -name '*ecj*.jar'
>> ./share/java/ecj.jar
>> plug local # export LD_LIBRARY_PATH=/usr/local/gcj/usr/local/lib
>> plug local #
>> plug local # ./bin/gcj  -I./lib/:./share/java/ecj.jar -c
>> /var/work/gcj/HelloWorld.java [B
>>      
> You don't want the -I part.
>
> I'd try stracing gcj to find out what's going on
>
>   $ strace -f -etrace=file gcj -c HelloWorld.java
>
> This will tell you where gcj is looking for its jarfiles.  Look for
> something like this:
>
> ...
> 547   execve("/home/aph/gcc/trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/ecj1", ["/home/aph/gcc/trunk/install/libe"..., "Hello.java", "-g1", "-fbootclasspath=./:/home/aph/gcc"..., "-g1", "-fsource=1.5", "-ftarget=1.5", "-fzip-dependency", "/tmp/ccXyDB9d.zip", "-fzip-target", "/tmp/ccipPqBc.jar"], [/* 42 vars */]) = 0
> ...
> 547   stat("/home/aph/gcc/trunk/install/share/java/ecj.jar", {st_mode=S_IFREG|0644, st_size=1377431, ...}) = 0
> 547   open("/home/aph/gcc/trunk/install/share/java/ecj.jar", O_RDONLY) = 3
> ...
>
> Andrew.
>
>    
Perfect.

I followed your suggestion; installed strace and reran the revised 
command line.  The output can be referenced at http://pastebin.com/m7cb292d5

The definitive line is:

172.  [pid  6423] access("/usr/local/share/java/ecj.jar", F_OK) = -1 
ENOENT (No such file or directory)

See also lines 81,82 and 85.

Basically, the problem is that compiler was looking for ecj.jar under a 
fixed(?) /usr/local/share path instead of the path where I had custom 
installed: /usr/local/gcj;  moreover it should have been looking under 
the full path of /usr/local/gcj/usr/local/share/java.

To work-around the path problem, I copied the java directory and its 
contents (on my server, there was no java directory under /usr/share) as 
in the following:

   plug local # pwd
   /usr/local/gcj/usr/local
   plug local # ls share/java
   ecj.jar  libgcj-4.5.0.jar  libgcj-tools-4.5.0.jar
   plug local # cp share/java/* /usr/local/share/java
   plug local #
   plug local # strace -f -etrace=file bin/gcj -c 
/var/work/gcj/HelloWorld.java
   plug local #
   plug local # ls
   bin  HelloWorld.o  include  lib  libexec  share
   plug local #


My successful run is posted at http://pastebin.com/m74e42dc9
I have Bug 42409 pending and will update it with attachments and this 
conclusion.

Thank you, Andrew.

- John L. Poole

Re: GCCMain not found & test suite errors fatal?

[Andrew Haley]

On 01/03/2010 06:14 PM, John Poole wrote:
> On 1/3/2010 8:28 AM, Andrew Haley wrote:
>>
>> I'd try stracing gcj to find out what's going on
>>
>>   $ strace -f -etrace=file gcj -c HelloWorld.java
>>
>> This will tell you where gcj is looking for its jarfiles.  Look for
>> something like this:
>>
>> ...
>> 547   execve("/home/aph/gcc/trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/ecj1", ["/home/aph/gcc/trunk/install/libe"..., "Hello.java", "-g1", "-fbootclasspath=./:/home/aph/gcc"..., "-g1", "-fsource=1.5", "-ftarget=1.5", "-fzip-dependency", "/tmp/ccXyDB9d.zip", "-fzip-target", "/tmp/ccipPqBc.jar"], [/* 42 vars */]) = 0
>> ...
>> 547   stat("/home/aph/gcc/trunk/install/share/java/ecj.jar", {st_mode=S_IFREG|0644, st_size=1377431, ...}) = 0
>> 547   open("/home/aph/gcc/trunk/install/share/java/ecj.jar", O_RDONLY) = 3

> Perfect.
> 
> I followed your suggestion; installed strace and reran the revised 
> command line.  The output can be referenced at http://pastebin.com/m7cb292d5
> 
> The definitive line is:
> 
> 172.  [pid  6423] access("/usr/local/share/java/ecj.jar", F_OK) = -1 
> ENOENT (No such file or directory)
> 
> See also lines 81,82 and 85.
> 
> Basically, the problem is that compiler was looking for ecj.jar under a 
> fixed(?) /usr/local/share path instead of the path where I had custom 
> installed: /usr/local/gcj;  moreover it should have been looking under 
> the full path of /usr/local/gcj/usr/local/share/java.

OK, so we need to know why that happened.  It might be a bug in gcj or
you might not have configured gcc correctly.  My guess is the latter,
but you never know.

Please look at the config.log in the top of the gcc build directory,
and cut-n-paste the configure line that's there.  I think I know
what's wrong, but I'll need to see it to be sure.

Andrew.

Re: GCCMain not found & test suite errors fatal?

[John Poole]

On 1/3/2010 10:31 AM, Andrew Haley wrote:
> On 01/03/2010 06:14 PM, John Poole wrote:
>    
>> On 1/3/2010 8:28 AM, Andrew Haley wrote:
>>      
>>> I'd try stracing gcj to find out what's going on
>>>
>>>    $ strace -f -etrace=file gcj -c HelloWorld.java
>>>
>>> This will tell you where gcj is looking for its jarfiles.  Look for
>>> something like this:
>>>
>>> ...
>>> 547   execve("/home/aph/gcc/trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/ecj1", ["/home/aph/gcc/trunk/install/libe"..., "Hello.java", "-g1", "-fbootclasspath=./:/home/aph/gcc"..., "-g1", "-fsource=1.5", "-ftarget=1.5", "-fzip-dependency", "/tmp/ccXyDB9d.zip", "-fzip-target", "/tmp/ccipPqBc.jar"], [/* 42 vars */]) = 0
>>> ...
>>> 547   stat("/home/aph/gcc/trunk/install/share/java/ecj.jar", {st_mode=S_IFREG|0644, st_size=1377431, ...}) = 0
>>> 547   open("/home/aph/gcc/trunk/install/share/java/ecj.jar", O_RDONLY) = 3
>>>        
>    
>> Perfect.
>>
>> I followed your suggestion; installed strace and reran the revised
>> command line.  The output can be referenced at http://pastebin.com/m7cb292d5
>>
>> The definitive line is:
>>
>> 172.  [pid  6423] access("/usr/local/share/java/ecj.jar", F_OK) = -1
>> ENOENT (No such file or directory)
>>
>> See also lines 81,82 and 85.
>>
>> Basically, the problem is that compiler was looking for ecj.jar under a
>> fixed(?) /usr/local/share path instead of the path where I had custom
>> installed: /usr/local/gcj;  moreover it should have been looking under
>> the full path of /usr/local/gcj/usr/local/share/java.
>>      
> OK, so we need to know why that happened.  It might be a bug in gcj or
> you might not have configured gcc correctly.  My guess is the latter,
> but you never know.
>
> Please look at the config.log in the top of the gcc build directory,
> and cut-n-paste the configure line that's there.  I think I know
> what's wrong, but I'll need to see it to be sure.
>
> Andrew.
>
>    
I added this to the bug, too.

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 #

Let me know if you need more of the config.log.

Re: GCCMain not found & test suite errors fatal?

[Andrew Haley]

On 01/03/2010 06:44 PM, John Poole wrote:
> On 1/3/2010 10:31 AM, Andrew Haley wrote:
>> On 01/03/2010 06:14 PM, John Poole wrote:

>>> Basically, the problem is that compiler was looking for ecj.jar under a
>>> fixed(?) /usr/local/share path instead of the path where I had custom
>>> installed: /usr/local/gcj;  moreover it should have been looking under
>>> the full path of /usr/local/gcj/usr/local/share/java.
>>>      
>> OK, so we need to know why that happened.  It might be a bug in gcj or
>> you might not have configured gcc correctly.  My guess is the latter,
>> but you never know.
>>
>> Please look at the config.log in the top of the gcc build directory,
>> and cut-n-paste the configure line that's there.  I think I know
>> what's wrong, but I'll need to see it to be sure.

> I added this to the bug, too.
> 
> 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

Oh right, that's the problem then.  You need to set the prefix with
--prefix=/usr/local/gcj and then do "make install" to install gcj in
the correct place.

I'm sure that's in the instructions.

Andrew.

Re: GCCMain not found & test suite errors fatal?

[Andrew Haley]

On 01/04/2010 11:28 AM, Bryce McKinlay wrote:
> On Sun, Jan 3, 2010 at 6:59 PM, Andrew Haley <aph@redhat.com> wrote:
> 
>>> It was created by configure, which was
>>> generated by GNU Autoconf 2.64.  Invocation command line was
>>>
>>>    $ ../trunk/configure --enable-languages=java
>>
>> Oh right, that's the problem then.  You need to set the prefix with
>> --prefix=/usr/local/gcj and then do "make install" to install gcj in
>> the correct place.
>>
>> I'm sure that's in the instructions.
> 
> As part of GCC, gcj "should" from in any location, however, even if you move
> it after installation. If this path is hardcoded then I'd say that's a bug.

Well, it's just compiled with

  gcj -Djava.class.path=$(ECJ_JAR)

It's a longstanding bug that ecj1 is not precompiled: it's interpreted
from the jarfile.  If we fix that bug by precompiling ecj1, then this
other bug will be fixed too.

Andrew.

Re: GCCMain not found & test suite errors fatal?

[John Poole]

On 1/4/2010 3:28 AM, Bryce McKinlay wrote:
> On Sun, Jan 3, 2010 at 6:59 PM, Andrew Haley <aph@redhat.com 
> <mailto:aph@redhat.com>> wrote:
>
>
>     > It was created by configure, which was
>     > generated by GNU Autoconf 2.64.  Invocation command line was
>     >
>     >    $ ../trunk/configure --enable-languages=java
>
>     Oh right, that's the problem then.  You need to set the prefix with
>     --prefix=/usr/local/gcj and then do "make install" to install gcj in
>     the correct place.
>
>     I'm sure that's in the instructions.
>
>
> As part of GCC, gcj "should" from in any location, however, even if 
> you move it after installation. If this path is hardcoded then I'd say 
> that's a bug.
>
> Bryce
>
Here's what caused me to do what I did:

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've recompiled (21 hours) using the --prefix parameter and compilation 
has completed; I've run the test suite - same result as before: 6 errors.

I'm waiting for a blessing to proceed with just  "make install" in Bug 
42409 as I read the above strong recommendation with great deference and 
really do not want to affect my existing GCC.

John L. Poole

Re: GCCMain not found & test suite errors fatal?

[Andrew Haley]

On 01/05/2010 02:43 AM, John Poole wrote:
> On 1/4/2010 3:28 AM, Bryce McKinlay wrote:
>> On Sun, Jan 3, 2010 at 6:59 PM, Andrew Haley <aph@redhat.com 
>> <mailto:aph@redhat.com>> wrote:
>>
>>
>>     > It was created by configure, which was
>>     > generated by GNU Autoconf 2.64.  Invocation command line was
>>     >
>>     >    $ ../trunk/configure --enable-languages=java
>>
>>     Oh right, that's the problem then.  You need to set the prefix with
>>     --prefix=/usr/local/gcj and then do "make install" to install gcj in
>>     the correct place.
>>
>>     I'm sure that's in the instructions.
>>
>>
>> As part of GCC, gcj "should" from in any location, however, even if 
>> you move it after installation. If this path is hardcoded then I'd say 
>> that's a bug.

> Here's what caused me to do what I did:
> 
> 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've recompiled (21 hours) using the --prefix parameter and compilation 
> has completed; I've run the test suite - same result as before: 6 errors.
> 
> I'm waiting for a blessing to proceed with just  "make install" in Bug 
> 42409 as I read the above strong recommendation with great deference and 
> really do not want to affect my existing GCC.

All becomes clear.

I've never come across anyone using DESTDIR=path-to-rootdir before, which
is why I've never seen this bug.  The usual way is to configure with
--prefix=path-to-rootdir followed by "make install".

I'll have a look at fixing this.

Andrew.

RFD: Precompile ecj [Was Re: GCCMain not found & test suite errors fatal?]

[Andrew Haley]

This makes ecj1 (and therefore gcj with Java source) much faster but
takes 1m30s of CPU on a very fast computer.  It doesn't really seem to
make the build longer on a multi-CPU box, since it runs in parallel with
the rest of the build AFAICS.  Do you think we can get away with this?

Andrew.


2010-01-06  Andrew Haley  <aph@redhat.com>

	* Makefile.am (ecjx_LDFLAGS): Always precompile AWT.

Index: Makefile.am
===================================================================
--- Makefile.am (revision 155475)
+++ Makefile.am (working copy)
@@ -1075,30 +1075,20 @@

 ## Build an ecjx from a .jar.
 ecjx_SOURCES = ecjx.cc
-## We use the BC ABI here so that we don't need to compile ecj.jar.
-## Hopefully the user has compiled it into his system .db.
-## However, even if not it will run reasonably quickly.
-
 ECJX_BASE_FLAGS = -findirect-dispatch \
        --main=org.eclipse.jdt.internal.compiler.batch.GCCMain

 if NATIVE

 ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS)
-
-if ENABLE_SHARED
-## Use ecj.jar at runtime.
-ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) -Djava.class.path=$(ECJ_JAR)
-else !ENABLE_SHARED
-## Use ecj.jar at compile time.
 ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) -fbootclasspath=$(BOOTCLASSPATH)
-endif !ENABLE_SHARED
-
 ecjx_LDADD = -L$(here)/.libs $(extra_ldflags)
 ecjx_DEPENDENCIES = libgcj.la libgcj.spec
 if BUILD_SUBLIBS
 ecjx_DEPENDENCIES += libgcj-noncore.la
+
 endif
+
 if USE_LIBGCJ_BC
 ecjx_DEPENDENCIES += libgcj_bc.la
 else

Re: RFD: Precompile ecj [Was Re: GCCMain not found & test suite errors fatal?]

[David Daney]

Andrew Haley wrote:
> This makes ecj1 (and therefore gcj with Java source) much faster but
> takes 1m30s of CPU on a very fast computer.  It doesn't really seem to
> make the build longer on a multi-CPU box, since it runs in parallel with
> the rest of the build AFAICS.  Do you think we can get away with this?
> 

Seems reasonable to me.


> Andrew.
> 
> 
> 2010-01-06  Andrew Haley  <aph@redhat.com>
> 
> 	* Makefile.am (ecjx_LDFLAGS): Always precompile AWT.


This changelog mentions AWT.  Is that correct?



> 
> Index: Makefile.am
> ===================================================================
> --- Makefile.am (revision 155475)
> +++ Makefile.am (working copy)
> @@ -1075,30 +1075,20 @@
> 
>  ## Build an ecjx from a .jar.
>  ecjx_SOURCES = ecjx.cc
> -## We use the BC ABI here so that we don't need to compile ecj.jar.
> -## Hopefully the user has compiled it into his system .db.
> -## However, even if not it will run reasonably quickly.
> -
>  ECJX_BASE_FLAGS = -findirect-dispatch \
>         --main=org.eclipse.jdt.internal.compiler.batch.GCCMain
> 
>  if NATIVE
> 
>  ecjx_LINK = $(GCJLINK) $(ecjx_LDFLAGS)
> -
> -if ENABLE_SHARED
> -## Use ecj.jar at runtime.
> -ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) -Djava.class.path=$(ECJ_JAR)
> -else !ENABLE_SHARED
> -## Use ecj.jar at compile time.
>  ecjx_LDFLAGS = $(ECJX_BASE_FLAGS) $(ECJ_BUILD_JAR) -fbootclasspath=$(BOOTCLASSPATH)
> -endif !ENABLE_SHARED
> -
>  ecjx_LDADD = -L$(here)/.libs $(extra_ldflags)
>  ecjx_DEPENDENCIES = libgcj.la libgcj.spec
>  if BUILD_SUBLIBS
>  ecjx_DEPENDENCIES += libgcj-noncore.la
> +
>  endif
> +
>  if USE_LIBGCJ_BC
>  ecjx_DEPENDENCIES += libgcj_bc.la
>  else
> 

Re: RFD: Precompile ecj [Was Re: GCCMain not found & test suite errors fatal?]

[Andrew Haley]

On 01/06/2010 04:59 PM, David Daney wrote:
> Andrew Haley wrote:
>> This makes ecj1 (and therefore gcj with Java source) much faster but
>> takes 1m30s of CPU on a very fast computer.  It doesn't really seem to
>> make the build longer on a multi-CPU box, since it runs in parallel with
>> the rest of the build AFAICS.  Do you think we can get away with this?
>>
> 
> Seems reasonable to me.
> 
> 
>> Andrew.
>>
>>
>> 2010-01-06  Andrew Haley  <aph@redhat.com>
>>
>> 	* Makefile.am (ecjx_LDFLAGS): Always precompile AWT.
> 
> 
> This changelog mentions AWT.  Is that correct?

Almost certainly not.  :-)

Thanks,
Andrew.

GCCMain not found & test suite errors fatal?

[John Poole]

I need help with two issues.

Background:
I'm trying to install a Java development and runtime environment on the 
Marvell SheevaPlug which runs off an ARMv5t processor.

I currently have Gentoo installed on my SheevaPlug.  Gentoo does not 
support Java for the ARMv5t platform.  I do know that Java works on the 
SheevaPlug as other people using an identical SheevaPlug have Ubuntu or 
other flavors of Linux installed and they are able to install a Java 
runtime and java based programs.  Moreover, Sun offers a run time 
environment, but Sun charges for it.  I would like to be able to set up 
a run time environment within Gentoo on the SheevaPlug without having to 
pay for a license or buy a black box technology.

I therefore undertook to compile icedtea6-1.6 and ran into a circular 
dependency of ANT.  ANT needs Java to install.  I logged Bug 387 with 
Iced Tea and I was advised to "use gcj to build openjdk build 
dependencies and bootstrap openjdk using gcj."  That endeavor brings me 
to this list.

I was able to successfully make Revision: 155206 of 
svn://gcc.gnu.org/svn/gcc/trunk.

I was unable to compile a test class, and logged Bug 42405; my problem 
had been failing to specify a library path; the comment "Make sure your 
install library path is in LD_LIBRARY_PATH." worked insofar as it got me 
past the error message 
"/usr/local/gcj/usr/local/bin/../libexec/gcc/armv5tel-unknown-linux-gnueabi/4.5.0/ecj1: 
error while loading shared libraries: libgcj_bc.so.1: cannot open shared 
object file: No such file or directory ."  By using these two commands, 
I was able to move past the problem:
    export LD_LIBRARY_PATH=/usr/local/gcj/usr/local/lib
    ./gcj -v -I /usr/local/gcj/usr/local/share/java/libgcj-4.5.0.jar 
/var/work/gcj/HelloWorld.java


Issue #1:
I then came across a new error, 
"org.eclipse.jdt.internal.compiler.batch.GCCMain" class not found, and 
opened Bug 42409 to track it.

It would be really helpful if in the GCJ documentation you had a simple 
test scenario which compiles (and runs?) a HelloWorld.java function.  
What often trips me up in Java is not having a class in the right path.  
In this case, the solution in Bug 42405 got me past that hurdle, but now 
with the problem in Bug 42409, I've most likely encountered another path 
type problem.  If I had a test scenario that identified all the path 
dependencies I could know that I have succeeded in getting something 
working.

Issue #2:
As an aside, I ran the test suite and had six errors.  Unfortunately, I 
do not know if these errors are show-stoppers or not and would 
appreciate anyone's opinion about whether they will block me from 
running a gcj compiler.  They details of the test suite are set forth in 
Bug 42409.

FAIL: calls execution - gij test
FAIL: findclass2 run
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
                 === libjava Summary ===

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

Given then above test results coupled with the warning in the 
documentation that some errors would occur, I'm thinking I've been very 
successful.  Unfortunately, I do not seem to be able to use what I have 
created in what should be a simple test (Issue #1 above).

Basically, I'd like to be to compile ANT with gcj and any other 
dependencies IcedTea will present me and be on my way.  If anyone thinks 
of other problems I may run into, or that I'm undertaking a really poor 
approach, please speak up.

Thank you for any help and guidance.

John L. Poole

Re: GCCMain not found & test suite errors fatal?

[Andrew Haley]

On 12/31/2009 02:36 PM, John Poole wrote:
> I need help with two issues.
> 
> Background:
> I'm trying to install a Java development and runtime environment on the 
> Marvell SheevaPlug which runs off an ARMv5t processor.
> 
> I currently have Gentoo installed on my SheevaPlug.  Gentoo does not 
> support Java for the ARMv5t platform.  I do know that Java works on the 
> SheevaPlug as other people using an identical SheevaPlug have Ubuntu or 
> other flavors of Linux installed and they are able to install a Java 
> runtime and java based programs.  Moreover, Sun offers a run time 
> environment, but Sun charges for it.  I would like to be able to set up 
> a run time environment within Gentoo on the SheevaPlug without having to 
> pay for a license or buy a black box technology.
> 
> I therefore undertook to compile icedtea6-1.6 and ran into a circular 
> dependency of ANT.  ANT needs Java to install.  I logged Bug 387 with 
> Iced Tea and I was advised to "use gcj to build openjdk build 
> dependencies and bootstrap openjdk using gcj."  That endeavor brings me 
> to this list.
> 
> I was able to successfully make Revision: 155206 of 
> svn://gcc.gnu.org/svn/gcc/trunk.
> 
> I was unable to compile a test class, and logged Bug 42405; my problem 
> had been failing to specify a library path; the comment "Make sure your 
> install library path is in LD_LIBRARY_PATH." worked insofar as it got me 
> past the error message 
> "/usr/local/gcj/usr/local/bin/../libexec/gcc/armv5tel-unknown-linux-gnueabi/4.5.0/ecj1: 
> error while loading shared libraries: libgcj_bc.so.1: cannot open shared 
> object file: No such file or directory ."  By using these two commands, 
> I was able to move past the problem:
>     export LD_LIBRARY_PATH=/usr/local/gcj/usr/local/lib
>     ./gcj -v -I /usr/local/gcj/usr/local/share/java/libgcj-4.5.0.jar 
> /var/work/gcj/HelloWorld.java
> 
> 
> Issue #1:
> I then came across a new error, 
> "org.eclipse.jdt.internal.compiler.batch.GCCMain" class not found, and 
> opened Bug 42409 to track it.

I imagine you haven't installed ecj.jar:

---------------------------------------------------------------------------
The following options apply to building `libgcj'.

General Options

--with-ecj-jar=filename

This option can be used to specify the location of an external jar
file containing the Eclipse Java compiler. A specially modified
version of this compiler is used by gcj to parse .java source
files. If this option is given, the `libjava' build will create and
install an ecj1 executable which uses this jar file at runtime.

If this option is not given, but an ecj.jar file is found in the
topmost source tree at configure time, then the `libgcj' build will
create and install ecj1, and will also install the discovered ecj.jar
into a suitable place in the install tree.

If ecj1 is not installed, then the user will have to supply one on his
path in order for gcj to properly parse .java source files. A suitable
jar is available from ftp://sourceware.org/pub/java/.
---------------------------------------------------------------------------

I suggest you grab ecj.jar and put it in install/share/java.  That
should get you a fully working gcj.

> Issue #2:
> As an aside, I ran the test suite and had six errors.  Unfortunately, I 
> do not know if these errors are show-stoppers or not and would 
> appreciate anyone's opinion about whether they will block me from 
> running a gcj compiler.  They details of the test suite are set forth in 
> Bug 42409.
> 
> FAIL: calls execution - gij test
> FAIL: findclass2 run
> 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
>                  === libjava Summary ===

I don't know about calls and findclass2, but Throw_2 is known to fail
on ARM.  This is a bug in the ARM unwinder which is AFAIK impossible
to fix.

> Given then above test results coupled with the warning in the
> documentation that some errors would occur, I'm thinking I've been
> very successful.

I think so.  Bootstrapping the entire Java world from zero is a hard
problem.

Andrew.