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.