icedtea6 build failures on alpha and armel using gcj

icedtea6 build failures on alpha and armel using gcj

[Matthias Klose]

Building icedtea6 on alpha and armel using a two stage bootstrap fails with 
different errors. These are no new errors, just rechecked the two stage 
bootstrap, because the one stage build fails to build cacao after the b18 
update. On alpha:

mkdir -p lib/rt
/home/doko/openjdk/openjdk-6-6b18~pre1/build/bootstrap/jdk1.6.0/bin/javac  -g -d 
lib/rt \
           -source 1.5 \
           -sourcepath \
 
'openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/corba/src/share/classes:/home/doko/openjdk/openjdk-6-6b18~pre1/build/generated' 
\
           -classpath /usr/lib/jvm/java-gcj/jre/lib/rt.jar \
           -bootclasspath \'\' @rt-source-files.txt ;
incorrect classpath: ''
----------
1. ERROR in 
/home/doko/openjdk/openjdk-6-6b18~pre1/build/openjdk/jdk/src/share/classes/sun/misc/FloatConsts.java 
(at line 52)
         public static final float   MIN_NORMAL      = 1.17549435E-38f;
                                                       ^^^^^^^^^^^^^^^
The literal 1.17549435E-38f of type float is out of range
----------
1 problem (1 error)make[1]: *** [stamps/rt-class-files.stamp] Error 255


I vaguely remember we had a patch in the past to back out some of the constants 
stuff.


On armel:

touch stamps/rewriter.stamp
mkdir -p rhino/rhino.{old,new}
(cd rhino/rhino.old ; jar xf /usr/share/java/js.jar)
/home/packages/openjdk/openjdk-6-6b18~pre1/build/bootstrap/jdk1.6.0/bin/java -cp 
/home/packages/openjdk/openjdk-6-6b18~pre1/build/rewriter \
           com.redhat.rewriter.ClassRewriter \
           /home/packages/openjdk/openjdk-6-6b18~pre1/build/rhino/rhino.old 
/home/packages/openjdk/openjdk-6-6b18~pre1/build/rhino/rhino.new \
           org.mozilla sun.org.mozilla
Exception in thread "main" java.lang.ExceptionInInitializerError
    <<No stacktrace available>>
Caused by: java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: 3
    <<No stacktrace available>>
Caused by: java.lang.ArrayIndexOutOfBoundsException: 3
    <<No stacktrace available>>
make[1]: *** [stamps/rewrite-rhino.stamp] Error 1
make[1]: Leaving directory `/home/packages/openjdk/openjdk-6-6b18~pre1/build'

This is reported as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860

   Matthias

Re: icedtea6 build failures on alpha and armel using gcj

[Andrew John Hughes]

On 27 February 2010 16:49, Matthias Klose <doko@ubuntu.com> wrote:
> Building icedtea6 on alpha and armel using a two stage bootstrap fails with
> different errors. These are no new errors, just rechecked the two stage
> bootstrap, because the one stage build fails to build cacao after the b18
> update. On alpha:
>
> mkdir -p lib/rt
> /home/doko/openjdk/openjdk-6-6b18~pre1/build/bootstrap/jdk1.6.0/bin/javac
>  -g -d lib/rt \
>          -source 1.5 \
>          -sourcepath \
>
> 'openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/corba/src/share/classes:/home/doko/openjdk/openjdk-6-6b18~pre1/build/generated'
> \
>          -classpath /usr/lib/jvm/java-gcj/jre/lib/rt.jar \
>          -bootclasspath \'\' @rt-source-files.txt ;
> incorrect classpath: ''
> ----------
> 1. ERROR in
> /home/doko/openjdk/openjdk-6-6b18~pre1/build/openjdk/jdk/src/share/classes/sun/misc/FloatConsts.java
> (at line 52)
>        public static final float   MIN_NORMAL      = 1.17549435E-38f;
>                                                      ^^^^^^^^^^^^^^^
> The literal 1.17549435E-38f of type float is out of range
> ----------
> 1 problem (1 error)make[1]: *** [stamps/rt-class-files.stamp] Error 255
>
>
> I vaguely remember we had a patch in the past to back out some of the
> constants stuff.
>

We do still have a patch.  It's applied to the ecj build.  Why are you
using ecj for a non-bootstrap build, as it appears here?

>
> On armel:
>
> touch stamps/rewriter.stamp
> mkdir -p rhino/rhino.{old,new}
> (cd rhino/rhino.old ; jar xf /usr/share/java/js.jar)
> /home/packages/openjdk/openjdk-6-6b18~pre1/build/bootstrap/jdk1.6.0/bin/java
> -cp /home/packages/openjdk/openjdk-6-6b18~pre1/build/rewriter \
>          com.redhat.rewriter.ClassRewriter \
>          /home/packages/openjdk/openjdk-6-6b18~pre1/build/rhino/rhino.old
> /home/packages/openjdk/openjdk-6-6b18~pre1/build/rhino/rhino.new \
>          org.mozilla sun.org.mozilla
> Exception in thread "main" java.lang.ExceptionInInitializerError
>   <<No stacktrace available>>
> Caused by: java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException: 3
>   <<No stacktrace available>>
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 3
>   <<No stacktrace available>>
> make[1]: *** [stamps/rewrite-rhino.stamp] Error 1
> make[1]: Leaving directory
> `/home/packages/openjdk/openjdk-6-6b18~pre1/build'
>
> This is reported as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
>
>  Matthias
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: icedtea6 build failures on alpha and armel using gcj

[Matthias Klose]

On 01.03.2010 20:54, Andrew John Hughes wrote:
> On 27 February 2010 16:49, Matthias Klose<doko@ubuntu.com>  wrote:
>> Building icedtea6 on alpha and armel using a two stage bootstrap fails with
>> different errors. These are no new errors, just rechecked the two stage
>> bootstrap, because the one stage build fails to build cacao after the b18
>> update. On alpha:
>>
>> mkdir -p lib/rt
>> /home/doko/openjdk/openjdk-6-6b18~pre1/build/bootstrap/jdk1.6.0/bin/javac
>>   -g -d lib/rt \
>>           -source 1.5 \
>>           -sourcepath \
>>
>> 'openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/corba/src/share/classes:/home/doko/openjdk/openjdk-6-6b18~pre1/build/generated'
>> \
>>           -classpath /usr/lib/jvm/java-gcj/jre/lib/rt.jar \
>>           -bootclasspath \'\' @rt-source-files.txt ;
>> incorrect classpath: ''
>> ----------
>> 1. ERROR in
>> /home/doko/openjdk/openjdk-6-6b18~pre1/build/openjdk/jdk/src/share/classes/sun/misc/FloatConsts.java
>> (at line 52)
>>         public static final float   MIN_NORMAL      = 1.17549435E-38f;
>>                                                       ^^^^^^^^^^^^^^^
>> The literal 1.17549435E-38f of type float is out of range
>> ----------
>> 1 problem (1 error)make[1]: *** [stamps/rt-class-files.stamp] Error 255
>>
>>
>> I vaguely remember we had a patch in the past to back out some of the
>> constants stuff.
>>
>
> We do still have a patch.  It's applied to the ecj build.  Why are you
> using ecj for a non-bootstrap build, as it appears here?

comparing the build logs on alpha and i386, this is the 
stamps/rt-class-files.stamp target, which succeeds to build on i386, but not on 
alpha. This target always uses the openjdk sourcepath, not the openjdk-ecj 
source path.

and it looks like the patch is applied, but ecj can't parse this value on alpha; 
the test program

   class Test {
         public static final float   MIN_NORMAL      = 1.17549435E-38f;
   }

fails to build:

----------
1. ERROR in Test.java (at line 2)
         public static final float   MIN_NORMAL      = 1.17549435E-38f;
                                                       ^^^^^^^^^^^^^^^
The literal 1.17549435E-38f of type float is out of range
----------


further, is it correct that the -ecj patch is applied to *both* the openjdk and 
openjdk-ecj directory?

$ ls -l build/openjdk*/jdk/src/share/classes/sun/misc/FloatConsts.java
-rw-rw-r-- 2 doko doko 4147 Feb 17 03:14 
build/openjdk-ecj/jdk/src/share/classes/sun/misc/FloatConsts.java
-rw-rw-r-- 2 doko doko 4147 Feb 17 03:14 
build/openjdk/jdk/src/share/classes/sun/misc/FloatConsts.java

these are still hard links.

   Matthias

Re: icedtea6 build failures on alpha and armel using gcj

[Andrew John Hughes]

On 8 March 2010 11:45, Matthias Klose <doko@ubuntu.com> wrote:
> On 01.03.2010 20:54, Andrew John Hughes wrote:
>>
>> On 27 February 2010 16:49, Matthias Klose<doko@ubuntu.com>  wrote:
>>>
>>> Building icedtea6 on alpha and armel using a two stage bootstrap fails
>>> with
>>> different errors. These are no new errors, just rechecked the two stage
>>> bootstrap, because the one stage build fails to build cacao after the b18
>>> update. On alpha:
>>>
>>> mkdir -p lib/rt
>>> /home/doko/openjdk/openjdk-6-6b18~pre1/build/bootstrap/jdk1.6.0/bin/javac
>>>  -g -d lib/rt \
>>>          -source 1.5 \
>>>          -sourcepath \
>>>
>>>
>>> 'openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/corba/src/share/classes:/home/doko/openjdk/openjdk-6-6b18~pre1/build/generated'
>>> \
>>>          -classpath /usr/lib/jvm/java-gcj/jre/lib/rt.jar \
>>>          -bootclasspath \'\' @rt-source-files.txt ;
>>> incorrect classpath: ''
>>> ----------
>>> 1. ERROR in
>>>
>>> /home/doko/openjdk/openjdk-6-6b18~pre1/build/openjdk/jdk/src/share/classes/sun/misc/FloatConsts.java
>>> (at line 52)
>>>        public static final float   MIN_NORMAL      = 1.17549435E-38f;
>>>                                                      ^^^^^^^^^^^^^^^
>>> The literal 1.17549435E-38f of type float is out of range
>>> ----------
>>> 1 problem (1 error)make[1]: *** [stamps/rt-class-files.stamp] Error 255
>>>
>>>
>>> I vaguely remember we had a patch in the past to back out some of the
>>> constants stuff.
>>>
>>
>> We do still have a patch.  It's applied to the ecj build.  Why are you
>> using ecj for a non-bootstrap build, as it appears here?
>
> comparing the build logs on alpha and i386, this is the
> stamps/rt-class-files.stamp target, which succeeds to build on i386, but not
> on alpha. This target always uses the openjdk sourcepath, not the
> openjdk-ecj source path.
>

Ok, so it occurs in the early bootstrap stage which still uses the
openjdk tree on IcedTea6 tree.  IcedTea7 uses the patched
bootstrap/ecj tree with the additional fixes to build the
bootstrapping classes, so I'll backport this to 6.

> and it looks like the patch is applied, but ecj can't parse this value on
> alpha; the test program
>
>  class Test {
>        public static final float   MIN_NORMAL      = 1.17549435E-38f;
>  }
>
> fails to build:
>
> ----------
> 1. ERROR in Test.java (at line 2)
>        public static final float   MIN_NORMAL      = 1.17549435E-38f;
>                                                      ^^^^^^^^^^^^^^^
> The literal 1.17549435E-38f of type float is out of range
> ----------
>
>
> further, is it correct that the -ecj patch is applied to *both* the openjdk
> and openjdk-ecj directory?
>
> $ ls -l build/openjdk*/jdk/src/share/classes/sun/misc/FloatConsts.java
> -rw-rw-r-- 2 doko doko 4147 Feb 17 03:14
> build/openjdk-ecj/jdk/src/share/classes/sun/misc/FloatConsts.java
> -rw-rw-r-- 2 doko doko 4147 Feb 17 03:14
> build/openjdk/jdk/src/share/classes/sun/misc/FloatConsts.java
>
> these are still hard links.

No it's specifically only applied to -ecj patches.  You should only
ever ship a build created from the openjdk tree and not
openjdk-ecj/boot (i.e. the second stage of a full build or the result
of a --with-openjdk/--disable-bootstrap build), which has a number of
features turned off (including Nimbus).

>
>  Matthias
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: icedtea6 build failures on alpha and armel using gcj

[Matthias Klose]

On 08.03.2010 13:34, Andrew John Hughes wrote:
>> further, is it correct that the -ecj patch is applied to *both* the openjdk
>> and openjdk-ecj directory?
>>
>> $ ls -l build/openjdk*/jdk/src/share/classes/sun/misc/FloatConsts.java
>> -rw-rw-r-- 2 doko doko 4147 Feb 17 03:14
>> build/openjdk-ecj/jdk/src/share/classes/sun/misc/FloatConsts.java
>> -rw-rw-r-- 2 doko doko 4147 Feb 17 03:14
>> build/openjdk/jdk/src/share/classes/sun/misc/FloatConsts.java
>>
>> these are still hard links.
>
> No it's specifically only applied to -ecj patches.

Wrong. The patch is applied in the openjdk-ecj directory, but because all files 
are hard links, it's applied in the openjdk directory as well. I don't see a way 
to have patch break the hard links while patching.

> You should only
> ever ship a build created from the openjdk tree and not
> openjdk-ecj/boot (i.e. the second stage of a full build or the result
> of a --with-openjdk/--disable-bootstrap build), which has a number of
> features turned off (including Nimbus).

sure, this is always done in the Debian/Ubuntu builds. I didn't check this for 
other distributions.

   Matthias

Re: icedtea6 build failures on alpha and armel using gcj

[Andrew John Hughes]

On 8 March 2010 12:41, Matthias Klose <doko@ubuntu.com> wrote:
> On 08.03.2010 13:34, Andrew John Hughes wrote:
>>>
>>> further, is it correct that the -ecj patch is applied to *both* the
>>> openjdk
>>> and openjdk-ecj directory?
>>>
>>> $ ls -l build/openjdk*/jdk/src/share/classes/sun/misc/FloatConsts.java
>>> -rw-rw-r-- 2 doko doko 4147 Feb 17 03:14
>>> build/openjdk-ecj/jdk/src/share/classes/sun/misc/FloatConsts.java
>>> -rw-rw-r-- 2 doko doko 4147 Feb 17 03:14
>>> build/openjdk/jdk/src/share/classes/sun/misc/FloatConsts.java
>>>
>>> these are still hard links.
>>
>> No it's specifically only applied to -ecj patches.
>
> Wrong. The patch is applied in the openjdk-ecj directory, but because all
> files are hard links, it's applied in the openjdk directory as well. I don't
> see a way to have patch break the hard links while patching.
>

Ok, I didn't realise it was a hard linked copy.  I'll disable that; we
don't want the ecj patches affecting the main tree.

>> You should only
>> ever ship a build created from the openjdk tree and not
>> openjdk-ecj/boot (i.e. the second stage of a full build or the result
>> of a --with-openjdk/--disable-bootstrap build), which has a number of
>> features turned off (including Nimbus).
>
> sure, this is always done in the Debian/Ubuntu builds. I didn't check this
> for other distributions.
>
>  Matthias
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

Re: icedtea6 build failures on alpha and armel using gcj

[Lennart Sorensen]

On Mon, Mar 08, 2010 at 12:44:59PM +0000, Andrew John Hughes wrote:
> Ok, I didn't realise it was a hard linked copy.  I'll disable that; we
> don't want the ecj patches affecting the main tree.

Applying a patch to a hardlink copy does not affect other copies.
patch creates a new file (hence breaking the hardlink).  At least when
using the patch command in the default way.  Maybe it has an option for
working in place on files, but I have never looked for such an option
so I have no idea.

The linux kernel package has been relying on this for years as have many
other packages.

Please don't change it since it won't make any difference other than to
take more diskspace and time to do a build.

-- 
Len Sorensen

Re: icedtea6 build failures on alpha and armel using gcj

[Andrew John Hughes]

On 8 March 2010 14:36, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
> On Mon, Mar 08, 2010 at 12:44:59PM +0000, Andrew John Hughes wrote:
>> Ok, I didn't realise it was a hard linked copy.  I'll disable that; we
>> don't want the ecj patches affecting the main tree.
>
> Applying a patch to a hardlink copy does not affect other copies.
> patch creates a new file (hence breaking the hardlink).  At least when
> using the patch command in the default way.  Maybe it has an option for
> working in place on files, but I have never looked for such an option
> so I have no idea.
>
> The linux kernel package has been relying on this for years as have many
> other packages.
>
> Please don't change it since it won't make any difference other than to
> take more diskspace and time to do a build.
>

That does make more sense as to what I was seeing; the openjdk-ecj
patches have never affected the main openjdk tree in the past that
I've seen.
Reverted.

> --
> Len Sorensen
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8