Re: icedtea6 build failures on alpha and armel using gcj

On 8 March 2010 11:45, Matthias Klose <doko-GeWIH/[email protected]> wrote:
> On 01.03.2010 20:54, Andrew John Hughes wrote:
>>
>> On 27 February 2010 16:49, Matthias Klose<doko-GeWIH/[email protected]>  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