Re: Trouble building gcj 4.8.1

[Mike Hearn <mike@plan99.net>]

Hmm, it seems there's one on my system already and it looks like the
script at the bottom of this mail. I guess it's from Debian and isn't
correct in some way. There's also an ecj1 that was installed when I
ran without --enable-java-maintainer-mode but it's in
$PREFIX/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/ecj1 - it seems
like running them gives the same outputs. Perhaps ecj1 was meant to be
installed as a symlink to the binary in libexec?

I put Andrew's script in my PATH and tried again, eventually got it
working. Unfortunately now I have another problem - it seems that
String.java is special, and that's the one I want to be recompiled. If
I introduce a syntax error into some  other class like
java.util.ArrayList and do a "rm compile-classes; make" in the libjava
build dir, it does indeed fail. Although it's impossible to see the
error as there are ~100,000+ warnings and I'm not sure yet how to
disable them :-) But, if I introduce a syntax error into String.java
and do the same thing, the compilation works fine.

I am not entirely surprised by the special-ness of String.java given
the comment at the top which says

  // WARNING: String is a CORE class in the bootstrap cycle. See the comments
  // in vm/reference/java/lang/Runtime for implications of this fact.

but the named file does not exist and the closest one that does
(VMRuntime.java) doesn't talk about bootstrap cycles at all.

Any idea why it's not building? Perhaps this is why the class file
didn't get refreshed last time ....



#! /bin/sh

case "$*" in
  *-bootclasspath*) ;;
  *)
    if [ ! -f /usr/lib/jvm/java-gcj/jre/lib/rt.jar ]; then
      bcoption="-bootclasspath /usr/share/java/libgcj-4.6.jar"
    fi
esac

if [ -x /usr/bin/ecj-gcj ]; then

    exec /usr/bin/ecj-gcj \
$bcoption ${1+"$@"}

else

    case $CLASSPATH in
      */usr/share/java/ecj.jar*) ;;
      */usr/share/java/eclipse-ecj.jar*) ;;
      *) CLASSPATH=${CLASSPATH:+$CLASSPATH:}/usr/share/java/eclipse-ecj.jar
    esac
    export CLASSPATH

    exec /usr/bin/gij-4.6 \
        -Dgnu.gcj.precompiled.db.path=/var/lib/gcj-$ver/classmap.db \
        -Djava.ext.dirs=/usr/lib/java-ext:/usr/share/java-ext \
        org.eclipse.jdt.internal.compiler.batch.Main $bcoption ${1+"$@"}

fi

On Mon, Jun 24, 2013 at 7:26 PM, Andrew Haley <aph@redhat.com> wrote:
> On 06/24/2013 06:17 PM, Mike Hearn wrote:
>>> It should have happened the last time there was a Classpath import.
>>> You should be able to see this in the revision history.
>>
>> Seems like it didn't always happen - compare:
>>
>> http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/classpath/java/lang/?dir_pagestart=75
>> http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/classpath/lib/java/lang/String.class?view=log
>>
>> The last time String.java was touched was 6 months ago, but the class
>> file was last updated 15 months ago.
>>
>> If I could make --enable-java-maintainer-mode work then it wouldn't
>> matter, but maybe re-genning the class files and checking them in
>> would be a good idea, seeing as they're provided.
>
> OK, so let's try to find out why it doesn't work.  You must have an
> executable called ecj1 in your path for use by the build.  My ecj1 is:
>
> #!/bin/sh
> unset LD_LIBRARY_PATH
> gij -cp /home/aph/gcc/trunk/ecj.jar \
>     org.eclipse.jdt.internal.compiler.batch.GCCMain \
>     ${1+"$@"}
>
> Andrew.
>