Re: icedtea6 build failures on alpha and armel using gcj
On 8 March 2010 14:36, Lennart Sorensen wrote: > On Mon, Mar 08, 2010 at 12:44:59PM +, 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 -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/17c6771e1003080717p4bbae5cege27c47f1153b5...@mail.gmail.com
Re: icedtea6 build failures on alpha and armel using gcj
On Mon, Mar 08, 2010 at 12:44:59PM +, 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 -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100308143630.gm4...@caffeine.csclub.uwaterloo.ca
Re: icedtea6 build failures on alpha and armel using gcj
On 8 March 2010 12:41, Matthias Klose 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 -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/17c6771e1003080444o3991c1bck4ce0b234c6848...@mail.gmail.com
Re: icedtea6 build failures on alpha and armel using gcj
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 -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b94f065.60...@ubuntu.com
Re: icedtea6 build failures on alpha and armel using gcj
On 8 March 2010 11:45, Matthias Klose wrote:
> On 01.03.2010 20:54, Andrew John Hughes wrote:
>>
>> On 27 February 2010 16:49, Matthias Klose 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
--
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/17c6771e1003080434r30405864v4e362752bc146...@mail.gmail.com
Re: icedtea6 build failures on alpha and armel using gcj
On 01.03.2010 20:54, Andrew John Hughes wrote:
On 27 February 2010 16:49, Matthias Klose 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
--
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b94e374.9090...@ubuntu.com
Re: icedtea6 build failures on alpha and armel using gcj
On 27 February 2010 16:49, Matthias Klose 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
> <>
> Caused by: java.lang.RuntimeException:
> java.lang.ArrayIndexOutOfBoundsException: 3
> <>
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 3
> <>
> 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
--
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/17c6771e1003011154l556ea301h92e54ff2d457e...@mail.gmail.com
Re: icedtea6 build failures on alpha and armel using gcj
Am 27.02.2010 17:49, schrieb Matthias Klose: are/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-file For alpha, have you built with -mieee? And ARCH_DATA_MODEL=64 I remember at least these two things driving me crazy... -of -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b8a8101.8050...@linux-kernel.at
