From gnu_andrew at member.fsf.org  Thu Jan  1 00:49:41 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 1 Jan 2009 08:49:41 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>
Message-ID: <17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>

2009/1/1 Michael Franz <mvfranz at gmail.com>:
> Hi,
>
> I have been able to build IcedTea 7 on OS X.  I removed a bunch of patches
> and had to fake some stuff to get it to work.  I wanted to use zero and
> shark.  This is the version that prints:
> java version "1.7.0_0-fastdebug-bsd"
> IcedTea 1.9-pre-rb5fe6c65b574 Runtime Environment (build
> 1.7.0_0-fastdebug-bsd-b42)
> OpenJDK Core VM (build 14.0-b08, interpreted mode)
>
> Is this enough to tell if I was able to build with zero and shark?
>

'Core VM' shows that the zero VM has been built.  I'm not sure about
how to tell if Shark is being used -- Gary?
To build Shark, you would have needed LLVM.

> This is what I used to configure:
> ./configure --enable-zero
> --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
> --with-xalan2-jar=/opt/local/share/java/xalan.jar
> --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
> --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar --without-rhino
> --disable-liveconnect --with-project=bsd --with-openjdk
> --with-openjdk-home=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820
> --disable-xrender --enable-shark
>
> Some of my issues were because the BSD port is not completely up-to-date
> with OpenJDK 7.
>

Yes that's happened with a number of the other ports, though b40 up
seem to be able to use the same patches more or less.
If we can make the process easier, please let us know.

> Michael
>
> On Tue, Dec 30, 2008 at 2:31 AM, Andrew John Hughes
> <gnu_andrew at member.fsf.org> wrote:
>>
>> 2008/12/30 Michael Franz <mvfranz at gmail.com>:
>> > Hi,
>> >
>> > I tried to build IcedTea 7 using the --with-project=bsd option.  Most of
>> > my
>> > issues are with applying the patches.  I have not gone through all of
>> > them,
>> > but they seem to fail around the bsd specific lines.
>> >
>> > What would be the best way to handle these differences?
>> >
>> > Michael
>> >
>>
>> Let us know the specifics and we'll work out a solution.  As I say, we
>> enabled the option but no-one on the IcedTea team uses BSD so it
>> hasn't been tested.
>> --
>> Andrew :-)
>>
>> 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
>
>


-- 
Andrew :-)

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


From gnu_andrew at member.fsf.org  Thu Jan  1 00:50:48 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 1 Jan 2009 08:50:48 +0000
Subject: Power PC Build
In-Reply-To: <fee4d890812311306n52ccffbbnc968beec580c7ca1@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<20081228182936.GA7488@misty.eyesbeyond.com>
	<17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com>
	<fee4d890812291557r3ea59283pd6e5f2b770d07e20@mail.gmail.com>
	<860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com>
	<17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com>
	<860cb0120812302348t6620a544k22292f0b09cbbdc@mail.gmail.com>
	<fee4d890812311306n52ccffbbnc968beec580c7ca1@mail.gmail.com>
Message-ID: <17c6771e0901010050x5d9c5163n1031e01b5efd1444@mail.gmail.com>

2008/12/31 Michael Franz <mvfranz at gmail.com>:
> Eric,
>
> On Wed, Dec 31, 2008 at 2:48 AM, Eric Richardson <ekrichardson at gmail.com>
> wrote:
>>
>> Andrew,
>
> <snip>
>>
>> I built gcc 4.2 as this was available via MacPorts.
>>
>>  Icedtea still looks promising but now I'm stuck on the ALSA part of
>> configure.
>>
>> checking for ALSA... no
>> configure: error: Could not find alsa -   Try installing alsa-lib-devel.
>>
>> The only thing I could find remotely related was Libao2.
>
> To work around this I change configure.ac to change the ALSA to a warning
> instead of an error and then run autogen.sh
>
> --- configure.ac.orig   2008-12-31 16:03:56.000000000 -0500
> +++ configure.ac        2008-12-31 16:04:17.000000000 -0500
> @@ -436,7 +436,7 @@
>  PKG_CHECK_MODULES(ALSA, alsa,[ALSA_FOUND=yes],[ALSA_FOUND=no])
>  if test "x${ALSA_FOUND}" = xno
>  then
> -  AC_MSG_ERROR([Could not find alsa - \
> +  AC_MSG_WARN([Could not find alsa - \
>    Try installing alsa-lib-devel.])
>  fi
>  AC_SUBST(ALSA_CFLAGS)
>
> I figure I will deal with the ALSA error later if I ever get to them.
>
> Michael
>
>>
>> Note: the problem I had before fwas because I was missing pkg.m4 which in
>> turn got fixed when I installed xorg-libX11.
>>
>> ./configure: line 11562: syntax error near unexpected token `XPROTO,'
>> ./configure: line 11562: `PKG_CHECK_MODULES(XPROTO,
>> xproto,XPROTO_FOUND=yes,XPROTO_FOUND=no)
>>
>> Eric
>>
>
>
>

The check should really be Linux-specific.  I don't know what backend
the BSD ports use for sound (if any) but it won't be ALSA.  The same
applies to Solaris.
-- 
Andrew :-)

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


From mvfranz at gmail.com  Fri Jan  2 09:28:16 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Fri, 2 Jan 2009 12:28:16 -0500
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>
	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>
Message-ID: <fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>

On Thu, Jan 1, 2009 at 3:49 AM, Andrew John Hughes <
gnu_andrew at member.fsf.org> wrote:

> 2009/1/1 Michael Franz <mvfranz at gmail.com>:
> > Hi,
> >
> > I have been able to build IcedTea 7 on OS X.  I removed a bunch of
> patches
> > and had to fake some stuff to get it to work.  I wanted to use zero and
> > shark.  This is the version that prints:
> > java version "1.7.0_0-fastdebug-bsd"
> > IcedTea 1.9-pre-rb5fe6c65b574 Runtime Environment (build
> > 1.7.0_0-fastdebug-bsd-b42)
> > OpenJDK Core VM (build 14.0-b08, interpreted mode)
> >
> > Is this enough to tell if I was able to build with zero and shark?
> >
>
> 'Core VM' shows that the zero VM has been built.  I'm not sure about
> how to tell if Shark is being used -- Gary?
> To build Shark, you would have needed LLVM.
>

I didn't install LLVM.  I was expecting compilation error if something was
missing.  It might be that one of the patches I did not apply prevented the
shark code.


>
> > This is what I used to configure:
> > ./configure --enable-zero
> > --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
> > --with-xalan2-jar=/opt/local/share/java/xalan.jar
> > --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
> > --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar --without-rhino
> > --disable-liveconnect --with-project=bsd --with-openjdk
> >
> --with-openjdk-home=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820
> > --disable-xrender --enable-shark
> >
> > Some of my issues were because the BSD port is not completely up-to-date
> > with OpenJDK 7.
> >
>
> Yes that's happened with a number of the other ports, though b40 up
> seem to be able to use the same patches more or less.
> If we can make the process easier, please let us know.
>

These are the patches I did not apply.
patches/icedtea-copy-plugs.patch
patches/icedtea-headers.patch
patches/icedtea-libraries.patch
patches/icedtea-linker-options.patch
patches/icedtea-jsoundhs.patch
patches/icedtea-arch.patch
patches/icedtea-lc_ctype.patch
patches/icedtea-linker-libs-order.patch
patches/xrender/icedtea-001.patch
patches/ecj/icedtea-pr261.patch

I skipped these, since it was easier to not apply them, then to try and fix
why they did not apply correctly.

These two applied OK, but broke the build.
patches/icedtea-jdk-use-ssize_t.patch
patches/icedtea-bytebuffer-compact.patch

Looking at the ssize_t patch, it seems that maybe OpenJDK is inconsistent in
using this macro.  Since OS X uses ssize_t for SSIZE_T the logic to figure
this out is only for solaris and LP64.  If it is not one of those platfroms
it is int.
openjdk/jdk/src/share/hpi/export/hpi.h

bytebuffer depends on java.nio.Buffer.java having directMark as a package
private method.  This is not in the BSD port and I cannot confirm in OpenJDK
as the repo has been down for a number of days.


> > Michael
> >
> > On Tue, Dec 30, 2008 at 2:31 AM, Andrew John Hughes
> > <gnu_andrew at member.fsf.org> wrote:
> >>
> >> 2008/12/30 Michael Franz <mvfranz at gmail.com>:
> >> > Hi,
> >> >
> >> > I tried to build IcedTea 7 using the --with-project=bsd option.  Most
> of
> >> > my
> >> > issues are with applying the patches.  I have not gone through all of
> >> > them,
> >> > but they seem to fail around the bsd specific lines.
> >> >
> >> > What would be the best way to handle these differences?
> >> >
> >> > Michael
> >> >
> >>
> >> Let us know the specifics and we'll work out a solution.  As I say, we
> >> enabled the option but no-one on the IcedTea team uses BSD so it
> >> hasn't been tested.
> >> --
> >> Andrew :-)
> >>
> >> 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
> >
> >
>
>
> --
> Andrew :-)
>

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090102/f65f1f7c/attachment.html 

From gnu_andrew at member.fsf.org  Fri Jan  2 10:54:17 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 2 Jan 2009 18:54:17 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>
	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
Message-ID: <17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>

2009/1/2 Michael Franz <mvfranz at gmail.com>:
>
>
> On Thu, Jan 1, 2009 at 3:49 AM, Andrew John Hughes
> <gnu_andrew at member.fsf.org> wrote:
>>
>> 2009/1/1 Michael Franz <mvfranz at gmail.com>:
>> > Hi,
>> >
>> > I have been able to build IcedTea 7 on OS X.  I removed a bunch of
>> > patches
>> > and had to fake some stuff to get it to work.  I wanted to use zero and
>> > shark.  This is the version that prints:
>> > java version "1.7.0_0-fastdebug-bsd"
>> > IcedTea 1.9-pre-rb5fe6c65b574 Runtime Environment (build
>> > 1.7.0_0-fastdebug-bsd-b42)
>> > OpenJDK Core VM (build 14.0-b08, interpreted mode)
>> >
>> > Is this enough to tell if I was able to build with zero and shark?
>> >
>>
>> 'Core VM' shows that the zero VM has been built.  I'm not sure about
>> how to tell if Shark is being used -- Gary?
>> To build Shark, you would have needed LLVM.
>
> I didn't install LLVM.  I was expecting compilation error if something was
> missing.  It might be that one of the patches I did not apply prevented the
> shark code.
>

Strange, configure should fail if you do --enable-shark and there is no LLVM.

>>
>> > This is what I used to configure:
>> > ./configure --enable-zero
>> > --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
>> > --with-xalan2-jar=/opt/local/share/java/xalan.jar
>> > --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
>> > --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar --without-rhino
>> > --disable-liveconnect --with-project=bsd --with-openjdk
>> >
>> > --with-openjdk-home=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820
>> > --disable-xrender --enable-shark
>> >
>> > Some of my issues were because the BSD port is not completely up-to-date
>> > with OpenJDK 7.
>> >
>>
>> Yes that's happened with a number of the other ports, though b40 up
>> seem to be able to use the same patches more or less.
>> If we can make the process easier, please let us know.
>
> These are the patches I did not apply.

> patches/icedtea-copy-plugs.patch
> patches/icedtea-jsoundhs.patch

not sure how you managed to build without these, they turn off the
proprietary garbage

> patches/icedtea-headers.patch
> patches/icedtea-libraries.patch

These fix the build to use external versions of libjpeg, zlib, libpng, freetype.
Without these patches, you'll be using the in-tree copies which have
known security issues and will decay over time.

> patches/icedtea-linker-options.patch
> patches/icedtea-arch.patch
> patches/icedtea-lc_ctype.patch
> patches/icedtea-linker-libs-order.patch

This suggests you need some additional cases for the Mac OS linker/gcc.

> patches/xrender/icedtea-001.patch
> patches/ecj/icedtea-pr261.patch
>

These suggest a dated build drop used by the BSD port.

> I skipped these, since it was easier to not apply them, then to try and fix
> why they did not apply correctly.
>
> These two applied OK, but broke the build.
> patches/icedtea-jdk-use-ssize_t.patch
> patches/icedtea-bytebuffer-compact.patch
>
> Looking at the ssize_t patch, it seems that maybe OpenJDK is inconsistent in
> using this macro.  Since OS X uses ssize_t for SSIZE_T the logic to figure
> this out is only for solaris and LP64.  If it is not one of those platfroms
> it is int.
> openjdk/jdk/src/share/hpi/export/hpi.h
>
> bytebuffer depends on java.nio.Buffer.java having directMark as a package
> private method.  This is not in the BSD port and I cannot confirm in OpenJDK
> as the repo has been down for a number of days.
>

It's discardMark() and yes, this is new in b42 IIRC.  I suggest the
BSD team look at updating their tree.

>>
>> > Michael
>> >
>> > On Tue, Dec 30, 2008 at 2:31 AM, Andrew John Hughes
>> > <gnu_andrew at member.fsf.org> wrote:
>> >>
>> >> 2008/12/30 Michael Franz <mvfranz at gmail.com>:
>> >> > Hi,
>> >> >
>> >> > I tried to build IcedTea 7 using the --with-project=bsd option.  Most
>> >> > of
>> >> > my
>> >> > issues are with applying the patches.  I have not gone through all of
>> >> > them,
>> >> > but they seem to fail around the bsd specific lines.
>> >> >
>> >> > What would be the best way to handle these differences?
>> >> >
>> >> > Michael
>> >> >
>> >>
>> >> Let us know the specifics and we'll work out a solution.  As I say, we
>> >> enabled the option but no-one on the IcedTea team uses BSD so it
>> >> hasn't been tested.
>> >> --
>> >> Andrew :-)
>> >>
>> >> 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
>> >
>> >
>>
>>
>> --
>> Andrew :-)
>
> Michael
>



-- 
Andrew :-)

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


From ekrichardson at gmail.com  Fri Jan  2 11:19:00 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Fri, 2 Jan 2009 11:19:00 -0800
Subject: Power PC Build
In-Reply-To: <fee4d890812311306n52ccffbbnc968beec580c7ca1@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<20081228182936.GA7488@misty.eyesbeyond.com>
	<17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com>
	<fee4d890812291557r3ea59283pd6e5f2b770d07e20@mail.gmail.com>
	<860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com>
	<17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com>
	<860cb0120812302348t6620a544k22292f0b09cbbdc@mail.gmail.com>
	<fee4d890812311306n52ccffbbnc968beec580c7ca1@mail.gmail.com>
Message-ID: <860cb0120901021119l48e53b13x94b905fde5455c64@mail.gmail.com>

Michael,

I was able to get through the configure process. Thanks.

Eric

On Wed, Dec 31, 2008 at 1:06 PM, Michael Franz <mvfranz at gmail.com> wrote:

> Eric,
>
> On Wed, Dec 31, 2008 at 2:48 AM, Eric Richardson <ekrichardson at gmail.com>wrote:
>
>> Andrew,
>
> <snip>
>
>> I built gcc 4.2 as this was available via MacPorts.
>>
>>  Icedtea still looks promising but now I'm stuck on the ALSA part of
>> configure.
>>
>> checking for ALSA... no
>> configure: error: Could not find alsa -   Try installing alsa-lib-devel.
>>
>> The only thing I could find remotely related was Libao2.
>>
>
> To work around this I change configure.ac to change the ALSA to a warning
> instead of an error and then run autogen.sh
>
> --- configure.ac.orig   2008-12-31 16:03:56.000000000 -0500
> +++ configure.ac        2008-12-31 16:04:17.000000000 -0500
> @@ -436,7 +436,7 @@
>  PKG_CHECK_MODULES(ALSA, alsa,[ALSA_FOUND=yes],[ALSA_FOUND=no])
>  if test "x${ALSA_FOUND}" = xno
>  then
> -  AC_MSG_ERROR([Could not find alsa - \
> +  AC_MSG_WARN([Could not find alsa - \
>    Try installing alsa-lib-devel.])
>  fi
>  AC_SUBST(ALSA_CFLAGS)
>
> I figure I will deal with the ALSA error later if I ever get to them.
>
> Michael
>
>
>>
>> Note: the problem I had before fwas because I was missing pkg.m4 which in
>> turn got fixed when I installed xorg-libX11.
>>
>> ./configure: line 11562: syntax error near unexpected token `XPROTO,'
>> ./configure: line 11562: `PKG_CHECK_MODULES(XPROTO,
>> xproto,XPROTO_FOUND=yes,XPROTO_FOUND=no)
>>
>> Eric
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090102/933de2a1/attachment.html 

From ekrichardson at gmail.com  Fri Jan  2 13:32:24 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Fri, 2 Jan 2009 13:32:24 -0800
Subject: Power PC Build
In-Reply-To: <17c6771e0812310746i413e95bbl99813bf99b989496@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<20081228182936.GA7488@misty.eyesbeyond.com>
	<17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com>
	<fee4d890812291557r3ea59283pd6e5f2b770d07e20@mail.gmail.com>
	<860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com>
	<17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com>
	<860cb0120812302348t6620a544k22292f0b09cbbdc@mail.gmail.com>
	<17c6771e0812310746i413e95bbl99813bf99b989496@mail.gmail.com>
Message-ID: <860cb0120901021332l67719f69id5fd93ddf4e749a@mail.gmail.com>

Andrew,

On Wed, Dec 31, 2008 at 7:46 AM, Andrew John Hughes <
gnu_andrew at member.fsf.org> wrote:

> 2008/12/31 Eric Richardson <ekrichardson at gmail.com>:
> > Andrew,
> >
> > On Mon, Dec 29, 2008 at 11:30 PM, Andrew John Hughes
> > <gnu_andrew at member.fsf.org> wrote:
> >>
> >> 2008/12/30 Eric Richardson <ekrichardson at gmail.com>:
> >> > Michael,
> >> >
> >> > On Mon, Dec 29, 2008 at 3:57 PM, Michael Franz <mvfranz at gmail.com>
> >> > wrote:
> >> >>
> >> >> Andrew,
> >> >>
> >> >> On Sun, Dec 28, 2008 at 6:26 PM, Andrew John Hughes
> >> >> <gnu_andrew at member.fsf.org> wrote:
> >> >> <snip>
> >> >>>
> >> >>> IcedTea[7] (http://icedtea.classpath.org/hg/icedtea) already has a
> >> >>> --with-project=bsd option for supporting using the BSD tree in place
> >> >>> of the main JDK7 tree.  It just needs testing.  I think supporting
> the
> >> >>> use of BSD as an alternate icedTea build is the better solution long
> >> >>> term.  All it really needs is someone will to try building on Mac
> >> >>> OS/BSD and to maintain it long-term by supplying us with patches.
> >> >>> No-one currently on the IcedTea team uses BSD or Mac OS X (AFAIK)
> but
> >> >>> we're certainly open to more contributors and to supporting more
> >> >>> platforms.  I'd much prefer this to forking zero support.  There are
> >> >>> also other features such as the web plugin, web start support, etc.
> in
> >> >>> IcedTea that may be useful for BSD and Mac OS X users.
> >> >>
> >> >> I made a quick attempt at building icedtea7 on OS X.  The autogen.sh
> >> >> fails
> >> >> with the following:
> >> >> onfigure.ac:4: installing `./config.guess'
> >> >> configure.ac:4: installing `./config.sub'
> >> >> configure.ac:2: installing `./install-sh'
> >> >> Makefile.am:1304: variable `PULSEAUDIO_SOURCES' is defined but no
> >> >> program
> >> >> or
> >> >> Makefile.am:1304: library has `PULSEAUDIO' as canonic name (possible
> >> >> typo)
> >> >> Makefile.am:1227: variable `JTREG_SOURCES' is defined but no program
> or
> >> >> Makefile.am:1227: library has `JTREG' as canonic name (possible typo)
> >> >>
> >> >> Also, I was not able to find IcedTea7 specific instructions.  Are
> there
> >> >> any?
> >> >>
> >> >> Michael
> >> >> <snip>
> >> >
> >> > I got this same error but tried configure anyway
> >> >
> >> > ./configure --with-openjdk-home=/Library/Java/Home --enable-zero=yes
> >> > --with-project=bsd
> --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
> >> >
> >> >
> --with-alt-jar=/System/LibrarFrameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar
> >> >
> >> > checking for libgcj-4.3.*.jar...
> >> > configure: error: "A LIBGCJ jar was not found."
> >> >
> >>
> >> Either use an OpenJDK/IcedTea build by adding --with-openjdk or
> >> specify --with-libgcj-jar to point to rt.jar.
> >> As I said in my previous email though, the libgcj build will not work
> >> with a non-Classpath/GCJ build environment.
> >> (--with-libgcj-jar is gone from IcedTea6, it will go from 7 when we next
> >> merge).
> >
> > This suggestion was very helpful. The problem using the JDK 5 on the Mac
> is
> > that instead of having an rt.jar they have classes.jar and ui.jar so you
> > can't use the --with-openjdk-home  so you must use
> >
> --with-libgcj-jar=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar
> > but unfortunately I had a typo in the path. I have been reading your
> posts
> > but much is new and I certainly don't understand it all.
> >
>
> --with-openjdk-home wouldn't be an option anyway, it's --with-gcj-home.
> There are basically three possible setups:
>
> * default build: does a bootstrap build (build with gcj+ecj first,
> then the built IcedTea), --with-gcj-home can be used to point to the
> JDK tree.
> * openjdk build: --with-openjdk turns this on, --with-openjdk-home
> points to the JDK tree.  The build JDK is expected to be a copy of raw
> OpenJDK.  Not sure how well tested this is anymore.
> * icedtea build --with-icedtea turns this on, --with-icedtea-home
> points to the JDK tree.  The build JDK is expected to be an earlier
> IcedTea.  It essentially does the second stage of the default build,
> and fails even with the oldest versions of IcedTea (those based on 7)
> as it expects some plugin classes to be in the existing IcedTea build.
>
> --with-libgcj-jar was dropped because it doesn't really fit in
> coherently.  It was only being used by the default build, but yet
> there was no equivalent for the openjdk or icedtea builds.  It doesn't
> get around the need for a correct JDK tree as libjvm.so will be
> expected to be present in jre/lib/${arch}/(client|server).  IcedTea
> seems to have adopted a hybrid approach of assuming and not assuming a
> JDK tree for the GCJ build and it simplifies things if we settle on a
> single approach.
>
> The JDK tree structure has become a defacto standard and is relied
> upon by quite a few Java applications, especially Apache ones.  I'm
> surprised that the JDK you have doesn't follow this.  We had a lot of
> problems with GNU Classpath when running applications that expected
> this structure of a tools.jar with the compiler, an rt.jar with the
> class library, etc. to the point that gcj-java-compat was created to
> provide a JDK-like tree for GCJ installs.  In turn, the IcedTea build
> expects this to be present as it is on current versions of Fedora,
> Debian, Ubuntu, etc. with the correct packages installed.
>
> It's actually easier to create such a tree than pass in numerous
> options to specify every little file.  Just create a tree with a
> jre/lib/rt.jar pointing to your class library and a
> jre/lib/${arch}/(client|server)/libjvm.so pointing to your libjvm.so
> e.g.
>
> $ find /usr/lib/gcj-jdk-4.3
> /usr/lib/gcj-jdk-4.3
> /usr/lib/gcj-jdk-4.3/bin
> /usr/lib/gcj-jdk-4.3/bin/jar
> /usr/lib/gcj-jdk-4.3/bin/java
> /usr/lib/gcj-jdk-4.3/bin/rmic
> /usr/lib/gcj-jdk-4.3/bin/keytool
> /usr/lib/gcj-jdk-4.3/bin/javac
> /usr/lib/gcj-jdk-4.3/bin/javah
> /usr/lib/gcj-jdk-4.3/bin/javap
> /usr/lib/gcj-jdk-4.3/bin/appletviewer
> /usr/lib/gcj-jdk-4.3/bin/jarsigner
> /usr/lib/gcj-jdk-4.3/bin/javadoc
> /usr/lib/gcj-jdk-4.3/bin/rmiregistry
> /usr/lib/gcj-jdk-4.3/jre
> /usr/lib/gcj-jdk-4.3/jre/bin
> /usr/lib/gcj-jdk-4.3/jre/bin/java
> /usr/lib/gcj-jdk-4.3/jre/bin/keytool
> /usr/lib/gcj-jdk-4.3/jre/bin/rmiregistry
> /usr/lib/gcj-jdk-4.3/jre/lib
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64/client
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64/client/libjvm.so
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64/libjawt.so
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64/server
> /usr/lib/gcj-jdk-4.3/jre/lib/amd64/server/libjvm.so
> /usr/lib/gcj-jdk-4.3/jre/lib/rt.jar
> /usr/lib/gcj-jdk-4.3/lib
> /usr/lib/gcj-jdk-4.3/lib/tools.jar
> /usr/lib/gcj-jdk-4.3/include
>
> The above is now created by the Gentoo gcj-jdk ebuild after a process
> of trial and error finding what was expected by different Java apps,
> etc.  Note that include is a symlink to gcj's include directory with
> jni.h.


Okay, I created the Java/JRE structure as you suggested and I am able to
configure icedtea6. The only thing I really didn't know is that libjvm.so is
libjvm.dylib on the MacOSX platform so I left them like that and will wait
to see the consequences. I used ppc64 as the architecture.

new-host:icedtea6 eric$ ./configure --enable-zero=yes --with-project=bsd
--with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
--with-gcj-home=/Library/Java/Home
--with-xalan2-jar=/opt/local/share/java/xalan.jar
--with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
--with-xerces2-jar=/opt/local/share/java/xercesImpl.jar
--with-rhino=/Users/eric/java-libs/js-engine.jar --disable-liveconnect

The --with-project=bsd of course is ignored in icedtea6.

I'm able to call make and it downloads the first piece but I have a md5sum
which doesn't understand the option --check. Don't know if this will be a
problem on other BSD platforms.

hotspot_md5sum="`gawk 'version==$1 {print $3}' version=14.0b08 \
      /Users/eric/java/icedtea6/hotspot.map`" ; \
    if ! echo "${hotspot_md5sum}  hotspot.tar.gz" \
      | /sw/bin/md5sum --check ; \
    then \
      if [ hotspot.tar.gz ] ; \
      then \
        mv hotspot.tar.gz hotspot.tar.gz.old ; \
      fi ; \
      changeset="`gawk 'version==$1 {print $2}' version=14.0b08 \
        /Users/eric/java/icedtea6/hotspot.map`" ; \
      /usr/local/bin/wget
http://hg.openjdk.java.net/jdk7/hotspot/hotspot/archive/${changeset}.tar.gz-O
hotspot.tar.gz ; \
    fi
/sw/bin/md5sum: illegal option -- -
usage: md5sum [-bv] [-c [file]] | [file...]
Generates or checks MD5 Message Digests
    -c  check message digests (default is generate)
    -v  verbose, print file names when checking
    -b  read files in binary mode

>
>
> > Removing the --with-libgcj-jar cuts off the path to what I am attempting
> to
> > do. (icedtea6 no longer works since I updated) If you can use any java 5
> > complier to create IcedTea JDK, the resultant can be used after that. If
> it
> > is possible to keep IcedTea like IcePick "which allows the OpenJDK
> language
> > tools (javac, javadoc, javah, javap, apt) to be built separately using
> any
> > 1.5 compliant Java compiler..." that would be great. Unless there is an
> > alternate way to point to the runtime jar.
> >
>

So I guess now I will have to wait for the removal of the --with-libgcj-jar
option in the icedtea7 code. I tried hg update and received no updates.


> --
> Andrew :-)
>
> 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
>

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090102/b910ff63/attachment.html 

From mvfranz at gmail.com  Fri Jan  2 15:39:17 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Fri, 2 Jan 2009 18:39:17 -0500
Subject: Power PC Build
In-Reply-To: <860cb0120901021332l67719f69id5fd93ddf4e749a@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<20081228182936.GA7488@misty.eyesbeyond.com>
	<17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com>
	<fee4d890812291557r3ea59283pd6e5f2b770d07e20@mail.gmail.com>
	<860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com>
	<17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com>
	<860cb0120812302348t6620a544k22292f0b09cbbdc@mail.gmail.com>
	<17c6771e0812310746i413e95bbl99813bf99b989496@mail.gmail.com>
	<860cb0120901021332l67719f69id5fd93ddf4e749a@mail.gmail.com>
Message-ID: <fee4d890901021539x329232bfhf0d03ab24754cece@mail.gmail.com>

Eric,

On Fri, Jan 2, 2009 at 4:32 PM, Eric Richardson <ekrichardson at gmail.com>wrote:
<snip>

>
> I'm able to call make and it downloads the first piece but I have a md5sum
> which doesn't understand the option --check. Don't know if this will be a
> problem on other BSD platforms.
>
> hotspot_md5sum="`gawk 'version==$1 {print $3}' version=14.0b08 \
>       /Users/eric/java/icedtea6/hotspot.map`" ; \
>     if ! echo "${hotspot_md5sum}  hotspot.tar.gz" \
>       | /sw/bin/md5sum --check ; \
>     then \
>       if [ hotspot.tar.gz ] ; \
>       then \
>         mv hotspot.tar.gz hotspot.tar.gz.old ; \
>       fi ; \
>       changeset="`gawk 'version==$1 {print $2}' version=14.0b08 \
>         /Users/eric/java/icedtea6/hotspot.map`" ; \
>       /usr/local/bin/wget
> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/archive/${changeset}.tar.gz<http://hg.openjdk.java.net/jdk7/hotspot/hotspot/archive/$%7Bchangeset%7D.tar.gz>-O hotspot.tar.gz ; \
>     fi
> /sw/bin/md5sum: illegal option -- -
> usage: md5sum [-bv] [-c [file]] | [file...]
> Generates or checks MD5 Message Digests
>     -c  check message digests (default is generate)
>     -v  verbose, print file names when checking
>     -b  read files in binary mode
>

You can install coreutils from macports using the with_default_names variant
to put md5sum into /opt/local/bin .  This version will understand the
--check parameter.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090102/db393241/attachment.html 

From ekrichardson at gmail.com  Fri Jan  2 18:31:45 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Fri, 2 Jan 2009 18:31:45 -0800
Subject: Power PC Build
In-Reply-To: <fee4d890901021539x329232bfhf0d03ab24754cece@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<20081228182936.GA7488@misty.eyesbeyond.com>
	<17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com>
	<fee4d890812291557r3ea59283pd6e5f2b770d07e20@mail.gmail.com>
	<860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com>
	<17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com>
	<860cb0120812302348t6620a544k22292f0b09cbbdc@mail.gmail.com>
	<17c6771e0812310746i413e95bbl99813bf99b989496@mail.gmail.com>
	<860cb0120901021332l67719f69id5fd93ddf4e749a@mail.gmail.com>
	<fee4d890901021539x329232bfhf0d03ab24754cece@mail.gmail.com>
Message-ID: <860cb0120901021831w58e52680l6210b322d93255ba@mail.gmail.com>

Michael,

On Fri, Jan 2, 2009 at 3:39 PM, Michael Franz <mvfranz at gmail.com> wrote:

> Eric,
>
> On Fri, Jan 2, 2009 at 4:32 PM, Eric Richardson <ekrichardson at gmail.com>wrote:
> <snip>
>
>>
>> I'm able to call make and it downloads the first piece but I have a md5sum
>> which doesn't understand the option --check. Don't know if this will be a
>> problem on other BSD platforms.
>>
>> hotspot_md5sum="`gawk 'version==$1 {print $3}' version=14.0b08 \
>>       /Users/eric/java/icedtea6/hotspot.map`" ; \
>>     if ! echo "${hotspot_md5sum}  hotspot.tar.gz" \
>>       | /sw/bin/md5sum --check ; \
>>     then \
>>       if [ hotspot.tar.gz ] ; \
>>       then \
>>         mv hotspot.tar.gz hotspot.tar.gz.old ; \
>>       fi ; \
>>       changeset="`gawk 'version==$1 {print $2}' version=14.0b08 \
>>         /Users/eric/java/icedtea6/hotspot.map`" ; \
>>       /usr/local/bin/wget
>> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/archive/${changeset}.tar.gz<http://hg.openjdk.java.net/jdk7/hotspot/hotspot/archive/$%7Bchangeset%7D.tar.gz>-O hotspot.tar.gz ; \
>>     fi
>> /sw/bin/md5sum: illegal option -- -
>> usage: md5sum [-bv] [-c [file]] | [file...]
>> Generates or checks MD5 Message Digests
>>     -c  check message digests (default is generate)
>>     -v  verbose, print file names when checking
>>     -b  read files in binary mode
>>
>
> You can install coreutils from macports using the with_default_names
> variant to put md5sum into /opt/local/bin .  This version will understand
> the --check parameter.
>

I reviewed your previous post and list of macports loaded but wanted to post
this just in case it was applicable for others if they don't have the GNU
utilities. Glad you explained the with_default_names variant again though.
Thanks.


>
>
> Michael
>
> Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090102/44268040/attachment.html 

From mvfranz at gmail.com  Fri Jan  2 22:26:05 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sat, 3 Jan 2009 01:26:05 -0500
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>
	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
Message-ID: <fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>

Andrew,

I made another attempt from scratch at this (the repo is back online).  I
did not use the latest version the first time since it does not build with
out patches (the patches are in the pipeline and should show up soon).  I
applied patches manually before starting.  Additional notes below.

On Fri, Jan 2, 2009 at 1:54 PM, Andrew John Hughes <
gnu_andrew at member.fsf.org> wrote:

> 2009/1/2 Michael Franz <mvfranz at gmail.com>:
> >
> >
> > On Thu, Jan 1, 2009 at 3:49 AM, Andrew John Hughes
> > <gnu_andrew at member.fsf.org> wrote:
> >>
> >> 2009/1/1 Michael Franz <mvfranz at gmail.com>:
> >> > Hi,
> >> >
> >> > I have been able to build IcedTea 7 on OS X.  I removed a bunch of
> >> > patches
> >> > and had to fake some stuff to get it to work.  I wanted to use zero
> and
> >> > shark.  This is the version that prints:
> >> > java version "1.7.0_0-fastdebug-bsd"
> >> > IcedTea 1.9-pre-rb5fe6c65b574 Runtime Environment (build
> >> > 1.7.0_0-fastdebug-bsd-b42)
> >> > OpenJDK Core VM (build 14.0-b08, interpreted mode)
> >> >
> >> > Is this enough to tell if I was able to build with zero and shark?
> >> >
> >>
> >> 'Core VM' shows that the zero VM has been built.  I'm not sure about
> >> how to tell if Shark is being used -- Gary?
> >> To build Shark, you would have needed LLVM.
> >
> > I didn't install LLVM.  I was expecting compilation error if something
> was
> > missing.  It might be that one of the patches I did not apply prevented
> the
> > shark code.
> >
>
> Strange, configure should fail if you do --enable-shark and there is no
> LLVM.
>
I might have removed this check in configure.  This time I installed llvm
via macports and configure did not complain (well, it did before I installed
llvm).


>
> >>
> >> > This is what I used to configure:
> >> > ./configure --enable-zero
> >> > --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
> >> > --with-xalan2-jar=/opt/local/share/java/xalan.jar
> >> > --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
> >> > --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar
> --without-rhino
> >> > --disable-liveconnect --with-project=bsd --with-openjdk
> >> >
> >> >
> --with-openjdk-home=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820
> >> > --disable-xrender --enable-shark
> >> >
> >> > Some of my issues were because the BSD port is not completely
> up-to-date
> >> > with OpenJDK 7.
> >> >
> >>
> >> Yes that's happened with a number of the other ports, though b40 up
> >> seem to be able to use the same patches more or less.
> >> If we can make the process easier, please let us know.
> >
> > These are the patches I did not apply.
>
> > patches/icedtea-copy-plugs.patch
> > patches/icedtea-jsoundhs.patch
>

> not sure how you managed to build without these, they turn off the
> proprietary garbage
>
I create a new patch for the changes in copy-plugs.  I could not figure out
why jsoundhs fails, but the BSD port has guards on the logic, so I don't
think the patch is necessary.

>
> > patches/icedtea-headers.patch
> > patches/icedtea-libraries.patch
>
> These fix the build to use external versions of libjpeg, zlib, libpng,
> freetype.
> Without these patches, you'll be using the in-tree copies which have
> known security issues and will decay over time.
>
I was able to apply the changes in headers patch.  libraries still fails and
it was too large for me to look at this time around.

>
> > patches/icedtea-linker-options.patch
> > patches/icedtea-arch.patch
> > patches/icedtea-lc_ctype.patch
> > patches/icedtea-linker-libs-order.patch
>
> This suggests you need some additional cases for the Mac OS linker/gcc.
>

These seemed to be linux specific and not necessary for bsd.

>
> > patches/xrender/icedtea-001.patch
> > patches/ecj/icedtea-pr261.patch
> >
>
> These suggest a dated build drop used by the BSD port.
>
These worked with the updated repo.


>
> > I skipped these, since it was easier to not apply them, then to try and
> fix
> > why they did not apply correctly.
> >
> > These two applied OK, but broke the build.
> > patches/icedtea-jdk-use-ssize_t.patch
> > patches/icedtea-bytebuffer-compact.patch
> >
> > Looking at the ssize_t patch, it seems that maybe OpenJDK is inconsistent
> in
> > using this macro.  Since OS X uses ssize_t for SSIZE_T the logic to
> figure
> > this out is only for solaris and LP64.  If it is not one of those
> platfroms
> > it is int.
> > openjdk/jdk/src/share/hpi/export/hpi.h
> >
> > bytebuffer depends on java.nio.Buffer.java having directMark as a package
> > private method.  This is not in the BSD port and I cannot confirm in
> OpenJDK
> > as the repo has been down for a number of days.
> >
>
> It's discardMark() and yes, this is new in b42 IIRC.  I suggest the
> BSD team look at updating their tree.
>
I did get the name wrong.  It is in the tip of the BSD port.

>
> >>
> >> > Michael
> >> >
> >> > On Tue, Dec 30, 2008 at 2:31 AM, Andrew John Hughes
> >> > <gnu_andrew at member.fsf.org> wrote:
> >> >>
> >> >> 2008/12/30 Michael Franz <mvfranz at gmail.com>:
> >> >> > Hi,
> >> >> >
> >> >> > I tried to build IcedTea 7 using the --with-project=bsd option.
>  Most
> >> >> > of
> >> >> > my
> >> >> > issues are with applying the patches.  I have not gone through all
> of
> >> >> > them,
> >> >> > but they seem to fail around the bsd specific lines.
> >> >> >
> >> >> > What would be the best way to handle these differences?
> >> >> >
> >> >> > Michael
> >> >> >
> >> >>
> >> >> Let us know the specifics and we'll work out a solution.  As I say,
> we
> >> >> enabled the option but no-one on the IcedTea team uses BSD so it
> >> >> hasn't been tested.
> >> >> --
> >> >> Andrew :-)
> >> >>
> >> >> 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
> >> >
> >> >
> >>
> >>
> >> --
> >> Andrew :-)
> >
> > Michael
> >
> --
> Andrew :-)
>
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090103/a63a3802/attachment.html 

From mvfranz at gmail.com  Fri Jan  2 22:51:36 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sat, 3 Jan 2009 01:51:36 -0500
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>
	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
Message-ID: <fee4d890901022251j5fc36a19v6134b7a3672898e9@mail.gmail.com>

Another thing that I noticed this time around is that zero is in the bsd
port repo.  I think adding ICEDTEA_ZERO_BUILD=1 to the build command will
activate it.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090103/c131ca90/attachment.html 

From mvfranz at gmail.com  Sat Jan  3 11:36:44 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sat, 3 Jan 2009 14:36:44 -0500
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>
	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
Message-ID: <fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>

I have created the following patches that integrate shark build into the
bsd-port repo.  I have not been able to get it to compile, but wanted these
out there in case they are wrong and causing my problem.

I am currently stuck on this error:
/Users/mfranz/developer/icedtea/local-bsd/bootstrap/jdk1.6.0/bin/javah
-classpath
/Users/mfranz/developer/icedtea/local-bsd/openjdk/build/bsd-i586/hotspot/outputdir/bsd_i486_shark/product/../generated/saclasses
-d
/Users/mfranz/developer/icedtea/local-bsd/openjdk/build/bsd-i586/hotspot/outputdir/bsd_i486_shark/product/../generated
-jni sun.jvm.hotspot.debugger.sparc.SPARCThreadContext
make[7]: *** No rule to make target `shark_globals_x86.hpp', needed by
`incls/_precompiled.incl.gch'.  Stop.
make[6]: *** [the_vm] Error 2
make[5]: *** [productshark] Error 2
make[4]: *** [generic_buildshark] Error 2
make[3]: *** [productshark] Error 2
make[2]: *** [hotspot-build] Error 2
make[1]: *** [build_product_image] Error 2
make: *** [stamps/icedtea.stamp] Error 2

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090103/1b9d9974/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icedtea-bsd-shark.patch
Type: application/octet-stream
Size: 2931 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090103/1b9d9974/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icedtea-bsd-top-make.patch
Type: application/octet-stream
Size: 977 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090103/1b9d9974/attachment-0001.obj 

From aph at redhat.com  Sat Jan  3 12:08:04 2009
From: aph at redhat.com (Andrew Haley)
Date: Sat, 03 Jan 2009 20:08:04 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
Message-ID: <495FC5A4.8080600@redhat.com>

Michael Franz wrote:
> I have created the following patches that integrate shark build into the
> bsd-port repo.  I have not been able to get it to compile, but wanted these
> out there in case they are wrong and causing my problem.
> 
> I am currently stuck on this error:

Shark on x86 isn't really ready yet.  I've been debugging it and it's
starting to look OK, but it's not stable.

Andrew.


From aph at redhat.com  Sat Jan  3 13:05:11 2009
From: aph at redhat.com (Andrew Haley)
Date: Sat, 03 Jan 2009 21:05:11 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <495FC5A4.8080600@redhat.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com>
Message-ID: <495FD307.3030606@redhat.com>

Andrew Haley wrote:
> Michael Franz wrote:
>> I have created the following patches that integrate shark build into the
>> bsd-port repo.  I have not been able to get it to compile, but wanted these
>> out there in case they are wrong and causing my problem.
>>
>> I am currently stuck on this error:
> 
> Shark on x86 isn't really ready yet.  I've been debugging it and it's
> starting to look OK, but it's not stable.

Actually, I've been working on x86_64.  AFAIAA *nobody* has worked on
x86.  To be honest, I don't really know why you'd want to: the x86
Hotspot JIT is very good.

Andrew.


From mvfranz at gmail.com  Sat Jan  3 13:23:40 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sat, 3 Jan 2009 16:23:40 -0500
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <495FD307.3030606@redhat.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>
	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
Message-ID: <fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>

Andrew,

On Sat, Jan 3, 2009 at 4:05 PM, Andrew Haley <aph at redhat.com> wrote:

> Andrew Haley wrote:
> > Michael Franz wrote:
> >> I have created the following patches that integrate shark build into the
> >> bsd-port repo.  I have not been able to get it to compile, but wanted
> these
> >> out there in case they are wrong and causing my problem.
> >>
> >> I am currently stuck on this error:
> >
> > Shark on x86 isn't really ready yet.  I've been debugging it and it's
> > starting to look OK, but it's not stable.
>
> Actually, I've been working on x86_64.  AFAIAA *nobody* has worked on
> x86.  To be honest, I don't really know why you'd want to: the x86
> Hotspot JIT is very good.
>
> Andrew.
>
I am not necessarily interested in the using zero/shark on intel (32 or
64).  I am interested int getting zero/shark integrated into the bsd port
for other architectures to use.  Since the bsd-port can only be built on
intel (32/64) I figured it would be easier to integrate with a working build
than trying to do it on ppc which cannot build icedtea (no valid bootstrap
jdk).

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090103/aa44e3d5/attachment.html 

From aph at redhat.com  Sat Jan  3 14:04:16 2009
From: aph at redhat.com (Andrew Haley)
Date: Sat, 03 Jan 2009 22:04:16 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>	
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>	
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>	
	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>	
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>	
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>	
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>	
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>	
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
Message-ID: <495FE0E0.60703@redhat.com>

Michael Franz wrote:

> On Sat, Jan 3, 2009 at 4:05 PM, Andrew Haley <aph at redhat.com> wrote:
> 
>> Andrew Haley wrote:
>>> Michael Franz wrote:
>>>> I have created the following patches that integrate shark build into the
>>>> bsd-port repo.  I have not been able to get it to compile, but wanted
>> these
>>>> out there in case they are wrong and causing my problem.
>>>>
>>>> I am currently stuck on this error:
>>> Shark on x86 isn't really ready yet.  I've been debugging it and it's
>>> starting to look OK, but it's not stable.
>> Actually, I've been working on x86_64.  AFAIAA *nobody* has worked on
>> x86.  To be honest, I don't really know why you'd want to: the x86
>> Hotspot JIT is very good.

> I am not necessarily interested in the using zero/shark on intel (32 or
> 64).  I am interested int getting zero/shark integrated into the bsd port
> for other architectures to use.  Since the bsd-port can only be built on
> intel (32/64) I figured it would be easier to integrate with a working build
> than trying to do it on ppc which cannot build icedtea (no valid bootstrap
> jdk).

You might be OK with zero on x86 BSD, but almost certainly not with shark.
I presume the problem with ppc on BSD is that gcj doesn't work there either.

Andrew.


From ekrichardson at gmail.com  Sat Jan  3 17:40:23 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Sat, 3 Jan 2009 17:40:23 -0800
Subject: Power PC Build
In-Reply-To: <17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<20081228182936.GA7488@misty.eyesbeyond.com>
	<17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com>
	<fee4d890812291557r3ea59283pd6e5f2b770d07e20@mail.gmail.com>
	<860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com>
	<17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com>
Message-ID: <860cb0120901031740u5fbb5c4cud246b842cc396874@mail.gmail.com>

Andrew,

On Mon, Dec 29, 2008 at 11:30 PM, Andrew John Hughes <
gnu_andrew at member.fsf.org> wrote:

> 2008/12/30 Eric Richardson <ekrichardson at gmail.com>:
> <snip>
>
> Either use an OpenJDK/IcedTea build by adding --with-openjdk or
> specify --with-libgcj-jar to point to rt.jar.
> As I said in my previous email though, the libgcj build will not work
> with a non-Classpath/GCJ build environment.
> (--with-libgcj-jar is gone from IcedTea6, it will go from 7 when we next
> merge).


Do you know when this merge will take place?


> <snip>
> --
> Andrew :-)
>
> 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
>

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090103/ab5ce260/attachment.html 

From christian.thalinger at gmail.com  Sun Jan  4 01:51:29 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Sun, 04 Jan 2009 10:51:29 +0100
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <495FE0E0.60703@redhat.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>
	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
Message-ID: <1231062689.28600.2.camel@localhost.localdomain>

On Sat, 2009-01-03 at 22:04 +0000, Andrew Haley wrote:
> Michael Franz wrote:
> 
> > On Sat, Jan 3, 2009 at 4:05 PM, Andrew Haley <aph at redhat.com> wrote:
> > 
> >> Andrew Haley wrote:
> >>> Michael Franz wrote:
> >>>> I have created the following patches that integrate shark build into the
> >>>> bsd-port repo.  I have not been able to get it to compile, but wanted
> >> these
> >>>> out there in case they are wrong and causing my problem.
> >>>>
> >>>> I am currently stuck on this error:
> >>> Shark on x86 isn't really ready yet.  I've been debugging it and it's
> >>> starting to look OK, but it's not stable.
> >> Actually, I've been working on x86_64.  AFAIAA *nobody* has worked on
> >> x86.  To be honest, I don't really know why you'd want to: the x86
> >> Hotspot JIT is very good.
> 
> > I am not necessarily interested in the using zero/shark on intel (32 or
> > 64).  I am interested int getting zero/shark integrated into the bsd port
> > for other architectures to use.  Since the bsd-port can only be built on
> > intel (32/64) I figured it would be easier to integrate with a working build
> > than trying to do it on ppc which cannot build icedtea (no valid bootstrap
> > jdk).
> 
> You might be OK with zero on x86 BSD, but almost certainly not with shark.
> I presume the problem with ppc on BSD is that gcj doesn't work there either.

Michael, you can use CACAO or JamVM to bootstrap IcedTea.  For some
instructions see:

http://c1.complang.tuwien.ac.at/cacaowiki/IcedTea

- Christian



From doko at ubuntu.com  Sun Jan  4 13:59:32 2009
From: doko at ubuntu.com (Matthias Klose)
Date: Sun, 04 Jan 2009 22:59:32 +0100
Subject: how to build without precompiled headers?
Message-ID: <49613144.90706@ubuntu.com>

Trying to track down an ICE (internal compiler error), I need to build hotspot
without precompiled header files.  There is a macro USE_PRECOMPILED_HEADER
defined in openjdk/hotspot/make/*/makefiles/gcc.make, but just removing the
conditional around this definition still builds using precompiled header files.
How can you build without precompiled header files (even if it's a hack)?

  Matthias


From bugzilla-daemon at icedtea.classpath.org  Sun Jan  4 22:32:33 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 05 Jan 2009 06:32:33 +0000
Subject: [Bug 275] New: Java applet page crashes Firefox 3.0.5
Message-ID: <E1LJj0r-0006me-VK@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=275

           Summary: Java applet page crashes Firefox 3.0.5
           Product: IcedTea
           Version: unspecified
          Platform: PC
               URL: http://www.sjsu.edu/faculty/watkins/tassel.htm
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: neteler at gmail.com


Description of problem:

Firefox crashes when browsing to a page that has an applet. 
My system is a freshly installed 2009.0 PowerPack for x86_64. 


rpm -qil java-1.6.0-openjdk-plugin-1.6.0.0-0.16.b11.4mdv2009.0
Name        : java-1.6.0-openjdk-plugin    Relocations: (not relocatable)
Version     : 1.6.0.0                           Vendor: Mandriva
Release     : 0.16.b11.4mdv2009.0           Build Date: Mon 11 Aug 2008
11:27:13 PM CEST
Install Date: Mon 29 Dec 2008 10:53:44 PM CET      Build Host:
klodia.mandriva.com
Group       : Development/Java              Source RPM:
java-1.6.0-openjdk-1.6.0.0-0.16.b11.4mdv2009.0.src.rpm
Size        : 164818                           License: GPLv2 with exceptions
Signature   : DSA/SHA1, Fri 03 Oct 2008 01:26:55 AM CEST, Key ID
e7898ae070771ff3
Packager    : David Walluck <walluck at mandriva.org>
URL         : http://icedtea.classpath.org/
Summary     : OpenJDK Web Browser Plugin
Description :
The OpenJDK web browser plugin.
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so
/usr/lib64/mozilla
/usr/lib64/mozilla/plugins
/usr/share/doc/java-1.6.0-openjdk-plugin
/usr/share/doc/java-1.6.0-openjdk-plugin/README.plugin

Steps to Reproduce:
1. Start Firefox;
2. Browse to http://www.sjsu.edu/faculty/watkins/tassel.htm

-> crash, firefox 3.0.5 window disappears

uname -a
Linux localhost 2.6.27.7-server-1mnb #1 SMP Thu Dec 11 17:41:52 EST 2008 x86_64
Intel(R) Core(TM)2 CPU         T5500  @ 1.66GHz GNU/Linux

cat /etc/issue
Mandriva Linux release 2009.0 (Official) for x86_64
Kernel 2.6.27.7-server-1mnb on a Dual-processor x86_64 / \l

Originally reported to
- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=471882
- Mandriva: https://qa.mandriva.com/show_bug.cgi?id=45162


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From aph at redhat.com  Mon Jan  5 02:56:40 2009
From: aph at redhat.com (Andrew Haley)
Date: Mon, 05 Jan 2009 10:56:40 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <495FE0E0.60703@redhat.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>		<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>		<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>		<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>		<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>		<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>		<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>		<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>		<495FC5A4.8080600@redhat.com>
	<495FD307.3030606@redhat.com>	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
Message-ID: <4961E768.6090603@redhat.com>

Andrew Haley wrote:
> Michael Franz wrote:
> 
>> On Sat, Jan 3, 2009 at 4:05 PM, Andrew Haley <aph at redhat.com> wrote:
>>
>>> Andrew Haley wrote:
>>>> Michael Franz wrote:
>>>>> I have created the following patches that integrate shark build into the
>>>>> bsd-port repo.  I have not been able to get it to compile, but wanted
>>> these
>>>>> out there in case they are wrong and causing my problem.
>>>>>
>>>>> I am currently stuck on this error:
>>>> Shark on x86 isn't really ready yet.  I've been debugging it and it's
>>>> starting to look OK, but it's not stable.
>>> Actually, I've been working on x86_64.  AFAIAA *nobody* has worked on
>>> x86.  To be honest, I don't really know why you'd want to: the x86
>>> Hotspot JIT is very good.
> 
>> I am not necessarily interested in the using zero/shark on intel (32 or
>> 64).  I am interested int getting zero/shark integrated into the bsd port
>> for other architectures to use.  Since the bsd-port can only be built on
>> intel (32/64) I figured it would be easier to integrate with a working build
>> than trying to do it on ppc which cannot build icedtea (no valid bootstrap
>> jdk).
> 
> You might be OK with zero on x86 BSD, but almost certainly not with shark.
> I presume the problem with ppc on BSD is that gcj doesn't work there either.

Thinking about this a bit more, what we really need is to fix IcedTea so that
it cross-compiles.  We already have "make icedtea-against-ecj", which uses an
installed ecj to build the class files.  Cross-compiling hotspot itself is not
a huge problem either.

Andrew.


From mark at klomp.org  Mon Jan  5 03:13:42 2009
From: mark at klomp.org (Mark Wielaard)
Date: Mon, 05 Jan 2009 12:13:42 +0100
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <4961E768.6090603@redhat.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>
	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>  <4961E768.6090603@redhat.com>
Message-ID: <1231154022.3499.32.camel@dijkstra.wildebeest.org>

Hi (added Robert to the CC),

On Mon, 2009-01-05 at 10:56 +0000, Andrew Haley wrote:
> Thinking about this a bit more, what we really need is to fix IcedTea so that
> it cross-compiles.  We already have "make icedtea-against-ecj", which uses an
> installed ecj to build the class files.  Cross-compiling hotspot itself is not
> a huge problem either.

This is what Robert did to get IcedTea cross compiled for
ARM/OpenEmbedded:
http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/
He was hoping to contribute any needed changes back.

Cheers,

Mark



From aph at redhat.com  Mon Jan  5 03:20:55 2009
From: aph at redhat.com (Andrew Haley)
Date: Mon, 05 Jan 2009 11:20:55 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <1231154022.3499.32.camel@dijkstra.wildebeest.org>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>	
	<17c6771e0812292331u5081480aneb4abbe31d46032c@mail.gmail.com>	
	<fee4d890812312229p1b387aber821a8606d68b4feb@mail.gmail.com>	
	<17c6771e0901010049i4a22bec7lc3eb89b4f1cd0c25@mail.gmail.com>	
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>	
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>	
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>	
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>	
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>	
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>	
	<495FE0E0.60703@redhat.com> <4961E768.6090603@redhat.com>
	<1231154022.3499.32.camel@dijkstra.wildebeest.org>
Message-ID: <4961ED17.9040906@redhat.com>

Mark Wielaard wrote:
> Hi (added Robert to the CC),
> 
> On Mon, 2009-01-05 at 10:56 +0000, Andrew Haley wrote:
>> Thinking about this a bit more, what we really need is to fix IcedTea so that
>> it cross-compiles.  We already have "make icedtea-against-ecj", which uses an
>> installed ecj to build the class files.  Cross-compiling hotspot itself is not
>> a huge problem either.
> 
> This is what Robert did to get IcedTea cross compiled for
> ARM/OpenEmbedded:
> http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/
> He was hoping to contribute any needed changes back.

That looks right, but is it all of OpenJDK or just the OpenJDK class library
with Cacao?

In any case, we need this stuff in the tree or it will rot really quickly.

Andrew.


From aph at redhat.com  Mon Jan  5 03:37:44 2009
From: aph at redhat.com (Andrew Haley)
Date: Mon, 05 Jan 2009 11:37:44 +0000
Subject: changeset in /hg/icedtea6: 2008-12-24  Andrew Haley  <aph@redhat...
Message-ID: <hg.b97986da0d62.1231155464.2873452341184383832@icedtea.classpath.org>

changeset b97986da0d62 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=b97986da0d62
description:
	2008-12-24  Andrew Haley  <aph at redhat.com>

		* ports/hotspot/src/share/vm/shark/sharkFunction.cpp
		(SharkFunction::initialize): Work around bug in
		ciTypeFlow::Block::pre_order_at().
		* ports/hotspot/src/share/vm/shark/sharkCompiler.cpp
		(SharkCompiler::compile_method): Allow "*" as a wildcard.
		* ports/hotspot/src/share/vm/shark/sharkBuilder.hpp (llvm::IRBuilder):
		type2aelembytes now a mamber function.
		* ports/hotspot/src/share/vm/shark/sharkBlock.hpp (class
		SharkBlock): is_private_copy renamed is_backedge_copy.
		* ports/hotspot/src/share/vm/shark/sharkBlock.cpp (SharkBlock::parse):
		force_bci if there's a trap.
		* ports/hotspot/src/cpu/zero/vm/disassembler_zero.cpp: Delete
		everything.

diffstat:

1 file changed, 6 insertions(+)
Makefile.am |    6 ++++++

diffs (16 lines):

diff -r 136f40a0dae4 -r b97986da0d62 Makefile.am
--- a/Makefile.am	Wed Dec 24 13:12:52 2008 -0500
+++ b/Makefile.am	Mon Jan 05 11:37:36 2009 +0000
@@ -554,6 +554,12 @@ endif
 
 ICEDTEA_FSG_PATCHES =
 
+DISTRIBUTION_PATCHES = \
+	patches/mixtec-assertions.patch \
+	patches/mixtec-no-log-vm-output.patch \
+	patches/mixtec-no-print-vm-options.patch \
+	patches/mixtec-optimization.patch
+
 ICEDTEA_PATCHES = \
 	$(ZERO_PATCHES_COND) \
 	patches/icedtea-version.patch \


From aph at redhat.com  Mon Jan  5 03:42:45 2009
From: aph at redhat.com (Andrew Haley)
Date: Mon, 05 Jan 2009 11:42:45 +0000
Subject: changeset in /hg/icedtea6: 2009-01-05  Andrew Haley  <aph@redhat...
Message-ID: <hg.79f28ead8d7b.1231155765.2873452341184383832@icedtea.classpath.org>

changeset 79f28ead8d7b in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=79f28ead8d7b
description:
	2009-01-05  Andrew Haley  <aph at redhat.com>

		* Makefile.am (ICEDTEA_PATCHES): Fix bad checkin.

diffstat:

2 files changed, 20 insertions(+), 6 deletions(-)
ChangeLog   |   20 ++++++++++++++++++++
Makefile.am |    6 ------

diffs (43 lines):

diff -r b97986da0d62 -r 79f28ead8d7b ChangeLog
--- a/ChangeLog	Mon Jan 05 11:37:36 2009 +0000
+++ b/ChangeLog	Mon Jan 05 11:42:35 2009 +0000
@@ -1,3 +1,23 @@ 2008-12-24  Omair Majid  <omajid at redhat.
+2009-01-05  Andrew Haley  <aph at redhat.com>
+
+	* Makefile.am (ICEDTEA_PATCHES): Fix bad checkin.
+
+2008-12-24  Andrew Haley  <aph at redhat.com>
+
+	* ports/hotspot/src/share/vm/shark/sharkFunction.cpp
+	(SharkFunction::initialize): Work around bug in
+	ciTypeFlow::Block::pre_order_at().
+	* ports/hotspot/src/share/vm/shark/sharkCompiler.cpp 
+	(SharkCompiler::compile_method): Allow "*" as a wildcard.
+	* ports/hotspot/src/share/vm/shark/sharkBuilder.hpp (llvm::IRBuilder):
+	type2aelembytes now a mamber function.
+	* ports/hotspot/src/share/vm/shark/sharkBlock.hpp (class
+	SharkBlock): is_private_copy renamed is_backedge_copy.
+	* ports/hotspot/src/share/vm/shark/sharkBlock.cpp (SharkBlock::parse):
+	force_bci if there's a trap.
+	* ports/hotspot/src/cpu/zero/vm/disassembler_zero.cpp: Delete
+	everything.
+
 2008-12-24  Omair Majid  <omajid at redhat.com>
 
 	* patches/icedtea-a11y-property-change.patch: New file.
diff -r b97986da0d62 -r 79f28ead8d7b Makefile.am
--- a/Makefile.am	Mon Jan 05 11:37:36 2009 +0000
+++ b/Makefile.am	Mon Jan 05 11:42:35 2009 +0000
@@ -554,12 +554,6 @@ endif
 
 ICEDTEA_FSG_PATCHES =
 
-DISTRIBUTION_PATCHES = \
-	patches/mixtec-assertions.patch \
-	patches/mixtec-no-log-vm-output.patch \
-	patches/mixtec-no-print-vm-options.patch \
-	patches/mixtec-optimization.patch
-
 ICEDTEA_PATCHES = \
 	$(ZERO_PATCHES_COND) \
 	patches/icedtea-version.patch \


From aph at redhat.com  Mon Jan  5 03:50:37 2009
From: aph at redhat.com (Andrew Haley)
Date: Mon, 05 Jan 2009 11:50:37 +0000
Subject: Oops
Message-ID: <4961F40D.40301@redhat.com>

I made a mistake committing a Shark patch, but backed it out as soon as
I noticed.  Normal service is now resumed.  :-)

	2009-01-05  Andrew Haley  <aph at redhat.com>

		* Makefile.am (ICEDTEA_PATCHES): Fix bad checkin.

Andrew.



From bugzilla-daemon at icedtea.classpath.org  Mon Jan  5 07:40:53 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 05 Jan 2009 15:40:53 +0000
Subject: [Bug 274] NRC Java Web Clock doesn't function (openjdk/icedtea 6b14
	and icedtea plugin)
Message-ID: <E1LJrZV-0007QJ-AT@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=274


langel at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at icedtea.classpath|omajid at redhat.com
                   |.org                        |




-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Mon Jan  5 07:41:11 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 05 Jan 2009 15:41:11 +0000
Subject: [Bug 275] Java applet page crashes Firefox 3.0.5
Message-ID: <E1LJrZn-0007QW-9C@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=275


langel at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at icedtea.classpath|dbhole at redhat.com
                   |.org                        |




-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the assignee for the bug, or are watching the assignee.


From Coleen.Phillimore at Sun.COM  Mon Jan  5 09:27:04 2009
From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems)
Date: Mon, 05 Jan 2009 12:27:04 -0500
Subject: how to build without precompiled headers?
In-Reply-To: <49613144.90706@ubuntu.com>
References: <49613144.90706@ubuntu.com>
Message-ID: <496242E8.10509@sun.com>


I tried this on my new 8.10 ubuntu system at home and commenting out 
USE_PRECOMPILED_HEADER didn't use the precompiled header. The file 
_precompiled.incl is still produced but it's empty. I believe you have 
to do a make clean before your gcc.make change is used.

The version of gcc that I used was very picky about inlined functions 
not being defined in places where the other platforms were happy, so 
there were multiple warnings with this message. I have a patch file that 
resolves this, if you want it.
Also, on my 8.10 ubuntu, gcc version 4.1.forgot, I got an error building 
fastdebug (server compiler) which I haven't resolved.

/home/coleenp/hotspot/src/share/vm/libadt/port.hpp:40: error: 'void 
bcopy(const void*, void*, size_t)' redeclared inline without 
'gnu_inline' attribute

If you're trying to track down a compiler error building hotspot, try 
getting a preprocessed output file to narrow it down.
cd linux*/<target>
make <file that had error>.i

Hope this helps.
Coleen

On 01/04/09 16:59, Matthias Klose wrote:
> Trying to track down an ICE (internal compiler error), I need to build hotspot
> without precompiled header files.  There is a macro USE_PRECOMPILED_HEADER
> defined in openjdk/hotspot/make/*/makefiles/gcc.make, but just removing the
> conditional around this definition still builds using precompiled header files.
> How can you build without precompiled header files (even if it's a hack)?
>
>   Matthias
>   


From gnu_andrew at member.fsf.org  Mon Jan  5 09:53:58 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 5 Jan 2009 17:53:58 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <4961ED17.9040906@redhat.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com> <4961E768.6090603@redhat.com>
	<1231154022.3499.32.camel@dijkstra.wildebeest.org>
	<4961ED17.9040906@redhat.com>
Message-ID: <17c6771e0901050953i6337905al37bf2836a4cb2e37@mail.gmail.com>

2009/1/5 Andrew Haley <aph at redhat.com>:
> Mark Wielaard wrote:
>> Hi (added Robert to the CC),
>>
>> On Mon, 2009-01-05 at 10:56 +0000, Andrew Haley wrote:
>>> Thinking about this a bit more, what we really need is to fix IcedTea so that
>>> it cross-compiles.  We already have "make icedtea-against-ecj", which uses an
>>> installed ecj to build the class files.  Cross-compiling hotspot itself is not
>>> a huge problem either.
>>
>> This is what Robert did to get IcedTea cross compiled for
>> ARM/OpenEmbedded:
>> http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/
>> He was hoping to contribute any needed changes back.
>
> That looks right, but is it all of OpenJDK or just the OpenJDK class library
> with Cacao?
>
> In any case, we need this stuff in the tree or it will rot really quickly.
>
> Andrew.
>

+1

While a great development, the version of IcedTea the blog uses is not
even current.
-- 
Andrew :-)

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


From mark at klomp.org  Tue Jan  6 01:56:25 2009
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 06 Jan 2009 10:56:25 +0100
Subject: hg repos/forests backups (Was: serving forests over http)
In-Reply-To: <1231097494.3380.39.camel@hermans.wildebeest.org>
References: <1231097494.3380.39.camel@hermans.wildebeest.org>
Message-ID: <1231235785.3426.28.camel@dijkstra.wildebeest.org>

Hi,

On Sun, 2009-01-04 at 20:31 +0100, Mark Wielaard wrote:
> I was setting up a backup of the forests to provide some redundancy in
> case the server goes down again. But I am unable to convince
> hgwebdir.cgi (or actually hg serve) to provide forest support through
> http. fclone locally or through ssh works fine though.
> How did you configure hgwebdir to make fclone over http work?

Thanks to Kelly I figured some stuff out.

There is now a mirror of the IcedTea repos (icedtea, icedtea6, brandweg,
fedora, icepick, pulseaudio and the testrepo), the main OpenJDK repos
(jdk6 and jdk7 master forests) and a copy of the old openjdk svn and
openjdk6 code drop hg mirrors at: http://classpath.wildebeest.org/hg/
This is a read-only mirror that is synced once an hour.

The main issues setting this up were:

- The forest repo itself has moved. There are two:
  http://hg.akoha.org/hgforest/ (the main repo)
  http://www.bitbucket.org/pmezard/hgforest-crew/
  (for making forest work with the latest and greatest - but see below)

- hgwebdir.config isn't a real hgrc file, only parts of it are parsed.
  (In particular [extensions] aren't parsed)

- Some versions of hgwebdir don't pick up the default hgrc files.
  You might have to play with something like:
  import os
  os.environ["HGRCPATH"] = "/var/lib/hg/.hgrc:/etc/mercurial/hgrc"
  (where one of those hgrc files has the forest extension defined)

- It seems that whatever version of forest you use, the hgweb/http
  support only reliably works with mercurial 0.95. I couldn't get it to
  work with anything newer or older (local file system fclones or
  fclones through ssh do work fine with newer versions though, just the
  http versions - also those created with hg serve - don't.)

- Unfortunately 0.95 hgwebdir doesn't work nicely with nested (forest)
  repos. You will end up having to define every forest in full in your
  hgwebdir.config like:

  [paths]
  jdk6/corba = /hg/jdk6/corba
  jdk6/hotspot = /hg/jdk6/hotspot
  jdk6/jaxp = /hg/jdk6/jaxp
  jdk6/jaxws = /hg/jdk6/jaxws
  jdk6/jdk = /hg/jdk6/jdk
  jdk6/langtools = /hg/jdk6/langtools

  Which is a pity since with 1.1.2 you could just do:
  [paths]
  / = /hg/**
  (all assuming you have a top level /hg dir with all your repos)

- Mercurial 1.1 and higher support the fncache repo format, Mercurial
  0.95 won't be able to read these. So if you experimented with 1.1+
  then you will have to convert your repo first:
  http://www.selenic.com/mercurial/wiki/index.cgi/fncacheRepoFormat

- The hg --debug fclone ... option is a good way to see if the forest
  capabilities have been picked up, it will should show you something
  like:

  sending capabilities command
  capabilities: unbundle=HG10GZ,HG10BZ,HG10UN lookup forests changegroupsubset
  sending forests command

  If it doesn't work then the client will print:
  abort: Remote forests cannot be cloned because the other repository 
  doesn't support the forest extension.

Cheers,

Mark



From bugzilla-daemon at icedtea.classpath.org  Tue Jan  6 13:01:11 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 06 Jan 2009 21:01:11 +0000
Subject: [Bug 276] New: SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKJ31-0000je-Li@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=276

           Summary: SIGSEGV in 64 bit JDK 1.6 when using JNI, and both
                    library and Java app are threaded
           Product: IcedTea
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: bruce.roscherr at citi.com


I am getting a SIGSEGV from the JVM when I run an app that uses a large amount
of memory, calls a native library that is threaded, and the java app
subsequently uses threads. I hope someone is in the position to test this bug,
as it seems to need a lot of moving parts.

I have had the same bug when using a library from Intel, and from another
vendor, MOSEK. In both cases I was able to reproduce the bug with minor tweaks
to example code supplied by each vendor, hopefully thereby removing user error.
I ran both of these on RedHat (glibc-2.5 based) and Ubuntu (glibc-2.7) for
different JDK 1.6 releases, always with the same result.


The basic structure of the app that causes the crash is this:
1. Create a few large arrays, 4 arrays with 10 million elements each will do
the trick, and fill them with random numbers, call them A, B, C, D
2. Call a function that uses JNI to call a threaded C function, doesnn't need
to involve A, B, C or D
3. Spawn a couple of Java threads and manipulate the arrays you created
initially, do dumb things like A=B+C, D=B+C.

This should crash your 64 bit JVM. It always crashes after the call to the
native library while working in the Java threads.

Here is a crash log from one of these failures:
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000382c80dd4d, pid=11407, tid=1084881216
#
# Java VM: OpenJDK 64-Bit Server VM (1.6.0_0-b11 mixed mode linux-amd64)
# Problematic frame:
# C  [libpthread.so.0+0xdd4d]  raise+0x2d
#
# If you would like to submit a bug report, please visit:
#   http://icedtea.classpath.org/bugzilla
#

---------------  T H R E A D  ---------------

Current thread is native thread

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=-6 (FPE_FLTOVF),
si_addr=0x000164a800002c8f

Registers:
RAX=0x0000000000000000, RBX=0x0000000000000000, RCX=0xffffffffffffffff,
RDX=0x000000000000000b
RSP=0x0000000040a9f068, RBP=0x0000000040a9f130, RSI=0x0000000000002ca3,
RDI=0x0000000000002c8f
R8 =0x0000000003347050, R9 =0x0000000000000001, R10=0x0000000000000000,
R11=0x0000000000000202
R12=0x0000000000000000, R13=0x0000000000000000, R14=0x00002aabb59ab700,
R15=0x0000000000000020
RIP=0x000000382c80dd4d, EFL=0x0000000000000202, CSGSFS=0x0000000000000033,
ERR=0x0000000000000000
  TRAPNO=0x0000000000000000

Top of Stack: (sp=0x0000000040a9f068)
0x0000000040a9f068:   00002aabb589aa21 fffffffe7fffffff
0x0000000040a9f078:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f088:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f098:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0a8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0b8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0c8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0d8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0e8:   ffffffffffffffff 0000000000000000
0x0000000040a9f0f8:   0000000040aa0000 0000000000001000
0x0000000040a9f108:   0000000000000000 000000004963b8f2
0x0000000040a9f118:   000000001ced22d8 000000004963b8f2
0x0000000040a9f128:   000000000005e117 0000000000000000
0x0000000040a9f138:   000000382c8062f7 0000000000000000
0x0000000040a9f148:   0000000040a9f940 0000000000000000
0x0000000040a9f158:   0000000000000000 0000000000000000
0x0000000040a9f168:   0000000000000000 0000000000000000
0x0000000040a9f178:   0000000000000000 0000000000000000
0x0000000040a9f188:   0000000000000000 0000000000000000
0x0000000040a9f198:   0000000000000000 0000000000000000
0x0000000040a9f1a8:   0000000000000000 0000000000000000
0x0000000040a9f1b8:   0000000000000000 0000000000000000
0x0000000040a9f1c8:   0000000000000000 0000000040a9f940
0x0000000040a9f1d8:   5a917365255b1a74 0000000000000000
0x0000000040a9f1e8:   0000000000000000 0000000040aa0000
0x0000000040a9f1f8:   0000000000001000 5a91736565f2eb34
0x0000000040a9f208:   5a91735d09db78c9 0000000000000000
0x0000000040a9f218:   0000000000000000 0000000000000000
0x0000000040a9f228:   0000000000000000 0000000000000000
0x0000000040a9f238:   0000000000000000 0000000000000000
0x0000000040a9f248:   0000000040a9f940 0000000000000000
0x0000000040a9f258:   000000382bcd1e3d 0000000000000000 

Instructions: (pc=0x000000382c80dd4d)
0x000000382c80dd3d:   b8 ea 00 00 00 48 63 d1 48 63 f6 48 63 ff 0f 05
0x000000382c80dd4d:   48 3d 00 f0 ff ff 89 c2 77 03 89 d0 c3 48 8b 05 

Stack: [0x0000000040a8f000,0x0000000040aa0000],  sp=0x0000000040a9f068,  free
space=64k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libpthread.so.0+0xdd4d]  raise+0x2d


---------------  P R O C E S S  ---------------

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 PSYoungGen      total 305856K, used 131463K [0x00002aab5e4d0000,
0x00002aab73a20000, 0x00002aabb3a20000)
  eden space 262208K, 50% used
[0x00002aab5e4d0000,0x00002aab66531f88,0x00002aab6e4e0000)
  from space 43648K, 0% used
[0x00002aab70f80000,0x00002aab70f80000,0x00002aab73a20000)
  to   space 43648K, 0% used
[0x00002aab6e4e0000,0x00002aab6e4e0000,0x00002aab70f80000)
 PSOldGen        total 699072K, used 0K [0x00002aaab3a20000,
0x00002aaade4d0000, 0x00002aab5e4d0000)
  object space 699072K, 0% used
[0x00002aaab3a20000,0x00002aaab3a20000,0x00002aaade4d0000)
 PSPermGen       total 21248K, used 3417K [0x00002aaaae620000,
0x00002aaaafae0000, 0x00002aaab3a20000)
  object space 21248K, 16% used
[0x00002aaaae620000,0x00002aaaae9765e0,0x00002aaaafae0000)

Dynamic libraries:
00400000-00409000 r-xp 00000000 08:02 3521722                           
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java
00608000-0060a000 rw-p 00008000 08:02 3521722                           
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java
03188000-0345b000 rw-p 03188000 00:00 0 
40186000-40187000 ---p 40186000 00:00 0 
40187000-40287000 rwxp 40187000 00:00 0 
40287000-40288000 ---p 40287000 00:00 0 
40288000-40388000 rwxp 40288000 00:00 0 
40388000-40389000 ---p 40388000 00:00 0 
40389000-40489000 rwxp 40389000 00:00 0 
40489000-4048a000 ---p 40489000 00:00 0 
4048a000-4058a000 rwxp 4048a000 00:00 0 
4058a000-4058b000 ---p 4058a000 00:00 0 
4058b000-4068b000 rwxp 4058b000 00:00 0 
4068b000-4068c000 ---p 4068b000 00:00 0 
4068c000-4078c000 rwxp 4068c000 00:00 0 
4078c000-4078d000 ---p 4078c000 00:00 0 
4078d000-4088d000 rwxp 4078d000 00:00 0 
4088d000-4088e000 ---p 4088d000 00:00 0 
4088e000-4098e000 rwxp 4088e000 00:00 0 
4098e000-4098f000 ---p 4098e000 00:00 0 
4098f000-40a8f000 rwxp 4098f000 00:00 0 
40a8f000-40a90000 ---p 40a8f000 00:00 0 
40a90000-40aa0000 rwxp 40a90000 00:00 0 
40aa0000-40aa1000 ---p 40aa0000 00:00 0 
40aa1000-40e99000 rwxp 40aa1000 00:00 0 
40f10000-40f13000 ---p 40f10000 00:00 0 
40f13000-41011000 rwxp 40f13000 00:00 0 
41011000-41014000 ---p 41011000 00:00 0 
41014000-41112000 rwxp 41014000 00:00 0 
41112000-41115000 ---p 41112000 00:00 0 
41115000-41213000 rwxp 41115000 00:00 0 
41213000-41216000 ---p 41213000 00:00 0 
41216000-41314000 rwxp 41216000 00:00 0 
41314000-41317000 ---p 41314000 00:00 0 
41317000-41415000 rwxp 41317000 00:00 0 
41415000-41418000 ---p 41415000 00:00 0 
41418000-41516000 rwxp 41418000 00:00 0 
41516000-41519000 ---p 41516000 00:00 0 
41519000-41617000 rwxp 41519000 00:00 0 
41617000-41618000 ---p 41617000 00:00 0 
41618000-41718000 rwxp 41618000 00:00 0 
41718000-41719000 ---p 41718000 00:00 0 
41719000-42119000 rwxp 41719000 00:00 0 
42119000-4211c000 ---p 42119000 00:00 0 
4211c000-4221a000 rwxp 4211c000 00:00 0 
4221a000-4221b000 ---p 4221a000 00:00 0 
4221b000-42613000 rwxp 4221b000 00:00 0 
42613000-42614000 ---p 42613000 00:00 0 
42614000-42a0c000 rwxp 42614000 00:00 0 
42a0c000-42a0d000 ---p 42a0c000 00:00 0 
42a0d000-42e06000 rwxp 42a0d000 00:00 0 
42e06000-42e07000 ---p 42e06000 00:00 0 
42e07000-43200000 rwxp 42e07000 00:00 0 
43200000-43201000 ---p 43200000 00:00 0 
43201000-435fa000 rwxp 43201000 00:00 0 
435fa000-435fb000 ---p 435fa000 00:00 0 
435fb000-439f4000 rwxp 435fb000 00:00 0 
439f4000-439f7000 ---p 439f4000 00:00 0 
439f7000-43af5000 rwxp 439f7000 00:00 0 
43af5000-43af8000 ---p 43af5000 00:00 0 
43af8000-43bf6000 rwxp 43af8000 00:00 0 
382b800000-382b81a000 r-xp 00000000 08:02 2312950                       
/lib64/ld-2.5.so
382ba1a000-382ba1b000 r--p 0001a000 08:02 2312950                       
/lib64/ld-2.5.so
382ba1b000-382ba1c000 rw-p 0001b000 08:02 2312950                       
/lib64/ld-2.5.so
382bc00000-382bd4a000 r-xp 00000000 08:02 2312952                       
/lib64/libc-2.5.so
382bd4a000-382bf4a000 ---p 0014a000 08:02 2312952                       
/lib64/libc-2.5.so
382bf4a000-382bf4e000 r--p 0014a000 08:02 2312952                       
/lib64/libc-2.5.so
382bf4e000-382bf4f000 rw-p 0014e000 08:02 2312952                       
/lib64/libc-2.5.so
382bf4f000-382bf54000 rw-p 382bf4f000 00:00 0 
382c000000-382c002000 r-xp 00000000 08:02 1661404                       
/lib64/libdl-2.5.so
382c002000-382c202000 ---p 00002000 08:02 1661404                       
/lib64/libdl-2.5.so
382c202000-382c203000 r--p 00002000 08:02 1661404                       
/lib64/libdl-2.5.so
382c203000-382c204000 rw-p 00003000 08:02 1661404                       
/lib64/libdl-2.5.so
382c400000-382c404000 r-xp 00000000 08:02 3528267                       
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so
382c404000-382c603000 ---p 00004000 08:02 3528267                       
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so
382c603000-382c604000 rw-p 00003000 08:02 3528267                       
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so
382c800000-382c815000 r-xp 00000000 08:02 1661429                       
/lib64/libpthread-2.5.so
382c815000-382ca14000 ---p 00015000 08:02 1661429                       
/lib64/libpthread-2.5.so
382ca14000-382ca15000 r--p 00014000 08:02 1661429                       
/lib64/libpthread-2.5.so
382ca15000-382ca16000 rw-p 00015000 08:02 1661429                       
/lib64/libpthread-2.5.so
382ca16000-382ca1a000 rw-p 382ca16000 00:00 0 
382cc00000-382cc14000 r-xp 00000000 08:02 1883612                       
/usr/lib64/libz.so.1.2.3
382cc14000-382ce13000 ---p 00014000 08:02 1883612                       
/usr/lib64/libz.so.1.2.3
382ce13000-382ce14000 rw-p 00013000 08:02 1883612                       
/usr/lib64/libz.so.1.2.3
3830400000-3830407000 r-xp 00000000 08:02 2312958                       
/lib64/librt-2.5.so
3830407000-3830607000 ---p 00007000 08:02 2312958                       
/lib64/librt-2.5.so
3830607000-3830608000 r--p 00007000 08:02 2312958                       
/lib64/librt-2.5.so
3830608000-3830609000 rw-p 00008000 08:02 2312958                       
/lib64/librt-2.5.so
3831c00000-3831c0d000 r-xp 00000000 08:02 1661403                       
/lib64/libgcc_s-4.1.2-20080102.so.1
3831c0d000-3831e0d000 ---p 0000d000 08:02 1661403                       
/lib64/libgcc_s-4.1.2-20080102.so.1
3831e0d000-3831e0e000 rw-p 0000d000 08:02 1661403                       
/lib64/libgcc_s-4.1.2-20080102.so.1
3835e00000-3835e15000 r-xp 00000000 08:02 2313092                       
/lib64/libnsl-2.5.so
3835e15000-3836014000 ---p 00015000 08:02 2313092                       
/lib64/libnsl-2.5.so
3836014000-3836015000 r--p 00014000 08:02 2313092                       
/lib64/libnsl-2.5.so
3836015000-3836016000 rw-p 00015000 08:02 2313092                       
/lib64/libnsl-2.5.so
3836016000-3836018000 rw-p 3836016000 00:00 0 
2aaaaaaab000-2aaaaaad3000 rw-p 2aaaaaaab000 00:00 0 
2aaaaaad5000-2aaaaaad6000 r--p 2aaaaaad5000 00:00 0 
2aaaaaad6000-2aaaaaad7000 rwxp 2aaaaaad6000 00:00 0 
2aaaaaad7000-2aaaaaadf000 r-xp 00000000 08:02 3521163                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libhpi.so
2aaaaaadf000-2aaaaacde000 ---p 00008000 08:02 3521163                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libhpi.so
2aaaaacde000-2aaaaacdf000 rw-p 00007000 08:02 3521163                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libhpi.so
2aaaaacdf000-2aaaaace0000 rw-p 2aaaaacdf000 00:00 0 
2aaaaace0000-2aaaaace8000 rw-s 00000000 00:14 22856                     
/tmp/hsperfdata_brucer/11407
2aaaaad07000-2aaaaad11000 r-xp 00000000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaad11000-2aaaaaf10000 ---p 0000a000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaaf10000-2aaaaaf11000 r--p 00009000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaaf11000-2aaaaaf12000 rw-p 0000a000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaaf12000-2aaaaaf20000 r-xp 00000000 08:02 3521160                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libverify.so
2aaaaaf20000-2aaaab11f000 ---p 0000e000 08:02 3521160                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libverify.so
2aaaab11f000-2aaaab121000 rw-p 0000d000 08:02 3521160                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libverify.so
2aaaab121000-2aaaab14c000 r-xp 00000000 08:02 3521142                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
2aaaab14c000-2aaaab34c000 ---p 0002b000 08:02 3521142                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
2aaaab34c000-2aaaab350000 rw-p 0002b000 08:02 3521142                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
2aaaab350000-2aaaab357000 r-xp 00000000 08:02 3521161                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libzip.so
2aaaab357000-2aaaab556000 ---p 00007000 08:02 3521161                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libzip.so
2aaaab556000-2aaaab557000 rw-p 00006000 08:02 3521161                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libzip.so
2aaaab557000-2aaaab7c7000 rwxp 2aaaab557000 00:00 0 
2aaaab7c7000-2aaaae557000 rwxp 2aaaab7c7000 00:00 0 
2aaaae557000-2aaaae561000 rwxp 2aaaae557000 00:00 0 
2aaaae561000-2aaaae617000 rwxp 2aaaae561000 00:00 0 
2aaaae620000-2aaaafae0000 rwxp 2aaaae620000 00:00 0 
2aaaafae0000-2aaab3a20000 rwxp 2aaaafae0000 00:00 0 
2aaab3a20000-2aaade4d0000 rwxp 2aaab3a20000 00:00 0 
2aaade4d0000-2aab5e4d0000 rwxp 2aaade4d0000 00:00 0 
2aab5e4d0000-2aab73a20000 rwxp 2aab5e4d0000 00:00 0 
2aab73a20000-2aabb3a20000 rwxp 2aab73a20000 00:00 0 
2aabb3a20000-2aabb3a2b000 rwxp 2aabb3a20000 00:00 0 
2aabb3a2b000-2aabb3a4a000 rwxp 2aabb3a2b000 00:00 0 
2aabb3a4a000-2aabb3ba0000 rwxp 2aabb3a4a000 00:00 0 
2aabb3ba0000-2aabb3f9f000 rwxp 2aabb3ba0000 00:00 0 
2aabb3f9f000-2aabb404a000 rwxp 2aabb3f9f000 00:00 0 
2aabb404a000-2aabb424a000 rwxp 2aabb404a000 00:00 0 
2aabb424a000-2aabb43a1000 rwxp 2aabb424a000 00:00 0 
2aabb43a1000-2aabb47a1000 rwxp 2aabb43a1000 00:00 0 
2aabb47a1000-2aabb47ac000 rwxp 2aabb47a1000 00:00 0 
2aabb47ac000-2aabb47cb000 rwxp 2aabb47ac000 00:00 0 
2aabb47cb000-2aabb4969000 r--s 01803000 08:02 3521228                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
2aabb4969000-2aabb4ac7000 rw-p 2aabb4969000 00:00 0 
2aabb4ac7000-2aabb4ad0000 r--s 00060000 08:02 3521184                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/ext/gnome-java-bridge.jar
2aabb4ad0000-2aabb4ad2000 r--s 0000b000 08:05 68059640                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/mosek.jar
2aabb4ad2000-2aabb4ad5000 r--s 00039000 08:02 3521213                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/jsse.jar
2aabb4ad5000-2aabb4b25000 r-xp 00000000 08:05 68059648                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosekjava5_0.so
2aabb4b25000-2aabb4c25000 ---p 00050000 08:05 68059648                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosekjava5_0.so
2aabb4c25000-2aabb4c26000 rw-p 00050000 08:05 68059648                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosekjava5_0.so
2aabb4c26000-2aabb528c000 r-xp 00000000 08:05 68059641                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosek64.so.5.0
2aabb528c000-2aabb538b000 ---p 00666000 08:05 68059641                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosek64.so.5.0
2aabb538b000-2aabb53bd000 rw-p 00665000 08:05 68059641                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosek64.so.5.0
2aabb53bd000-2aabb53c0000 rw-p 2aabb53bd000 00:00 0 
2aabb53c0000-2aabb53fe000 r-xp 00000000 08:05 68059639                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libirc.so
2aabb53fe000-2aabb54fd000 ---p 0003e000 08:05 68059639                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libirc.so
2aabb54fd000-2aabb54ff000 rw-p 0003d000 08:05 68059639                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libirc.so
2aabb54ff000-2aabb5500000 rw-p 2aabb54ff000 00:00 0 
2aabb5500000-2aabb5765000 r-xp 00000000 08:05 68059657                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libimf.so
2aabb5765000-2aabb5864000 ---p 00265000 08:05 68059657                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libimf.so
2aabb5864000-2aabb5869000 rw-p 00264000 08:05 68059657                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libimf.so
2aabb5869000-2aabb58a9000 r-xp 00000000 08:05 68059643                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libguide.so
2aabb58a9000-2aabb59a8000 ---p 00040000 08:05 68059643                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libguide.so
2aabb59a8000-2aabb59ab000 rw-p 0003f000 08:05 68059643                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libguide.so
2aabb59ab000-2aabb59b1000 rw-p 2aabb59ab000 00:00 0 
2aabb59b1000-2aabb59d1000 r-xp 00000000 08:05 68059635                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libsvml.so
2aabb59d1000-2aabb5ad0000 ---p 00020000 08:05 68059635                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libsvml.so
2aabb5ad0000-2aabb5af4000 rw-p 0001f000 08:05 68059635                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libsvml.so
2aabb8000000-2aabb8021000 rw-p 2aabb8000000 00:00 0 
2aabb8021000-2aabbc000000 ---p 2aabb8021000 00:00 0 
2ba5d7d82000-2ba5d7d84000 rw-p 2ba5d7d82000 00:00 0 
2ba5d7dab000-2ba5d7dae000 rw-p 2ba5d7dab000 00:00 0 
2ba5d7dae000-2ba5d84ea000 r-xp 00000000 08:02 3521167                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
2ba5d84ea000-2ba5d86ea000 ---p 0073c000 08:02 3521167                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
2ba5d86ea000-2ba5d8762000 rw-p 0073c000 08:02 3521167                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
2ba5d8762000-2ba5d879b000 rw-p 2ba5d8762000 00:00 0 
2ba5d87c2000-2ba5d8844000 r-xp 00000000 08:02 1661430                   
/lib64/libm-2.5.so
2ba5d8844000-2ba5d8a43000 ---p 00082000 08:02 1661430                   
/lib64/libm-2.5.so
2ba5d8a43000-2ba5d8a44000 r--p 00081000 08:02 1661430                   
/lib64/libm-2.5.so
2ba5d8a44000-2ba5d8a45000 rw-p 00082000 08:02 1661430                   
/lib64/libm-2.5.so
7fffd2d12000-7fffd2d25000 rwxp 7fffd2d12000 00:00 0                     
[stack]
7fffd2d25000-7fffd2d28000 rw-p 7fffd2d25000 00:00 0 
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]

VM Arguments:
jvm_args: -Xms1024m -Xmx4096m 
java_command: qcqo1.qcqo1
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk.x86_64
PATH=/data2/r-project/bin:/home/brucer/bin:/work/loc0/prod/bbin:/work/loc2/prod/bbin:/work/loc2/prod/pbin:/work/loc2/prod/pybin:/work/loc2/prod/bin:/work/loc1/prod/bin:/data1/bruce/gcc/bin:/data2/r-project/bin:/home/brucer/bin:/work/loc0/prod/bbin:/work/loc2/prod/bbin:/work/loc2/prod/pbin:/work/loc2/prod/pybin:/work/loc2/prod/bin:/work/loc1/prod/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/brucer/bin:/work/loc2/prod/bin/hcsv:/work/loc0/prod/mod/utils:/home/brucer/bin:/home/brucer/bin:/work/loc2/prod/bin/hcsv:/work/loc0/prod/mod/utils
USERNAME=brucer
LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin:/data1/bruce/lib:/data2/r-project/lib64/R/lib:/data2/r-project/bin:/work/loc1/lib64:/work/opt/lib/wombat408:/usr/lib/oracle/10.2.0.4/client64/lib
SHELL=/bin/bash
DISPLAY=:0.0

Signal Handlers:
SIGSEGV: [libjvm.so+0x618cc0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x618cc0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGXFSZ: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x4e0340], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004


---------------  S Y S T E M  ---------------

OS:Red Hat Enterprise Linux Server release 5.2 (Tikanga)

uname:Linux 2.6.18-92.1.22.el5 #1 SMP Fri Dec 5 09:28:22 EST 2008 x86_64
libc:glibc 2.5 NPTL 2.5 
rlimit: STACK 10240k, CORE infinity, NPROC 135168, NOFILE 1024, AS infinity
load average:0.39 0.48 0.36

CPU:total 8 (4 cores per cpu, 1 threads per core) family 6 model 7 stepping 6,
cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3

Memory: 4k page, physical 16312852k(6475052k free), swap 8546540k(1728304k
free)

vm_info: OpenJDK 64-Bit Server VM (1.6.0_0-b11) for linux-amd64 JRE
(1.6.0_0-b11), built on Jul 25 2008 06:43:15 by "mockbuild" with gcc 4.1.2
20071124 (Red Hat 4.1.2-42)

time: Tue Jan  6 15:02:58 2009
elapsed time: 4 seconds


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From omajid at redhat.com  Tue Jan  6 14:31:42 2009
From: omajid at redhat.com (Omair Majid)
Date: Tue, 06 Jan 2009 22:31:42 +0000
Subject: changeset in /hg/icedtea6: 2009-01-06  Omair Majid  <omajid@redh...
Message-ID: <hg.fc5078fb4df1.1231281102.2873452341184383832@icedtea.classpath.org>

changeset fc5078fb4df1 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=fc5078fb4df1
description:
	2009-01-06  Omair Majid  <omajid at redhat.com>

	    * patches/icedtea-demo-swingapplet.patch: New file.
	    * Makefile.am (ICEDTEA_PATCHES): Apply the above.
	    * HACKING: Document the above.

diffstat:

4 files changed, 20 insertions(+), 1 deletion(-)
ChangeLog                              |    6 ++++++
HACKING                                |    1 +
Makefile.am                            |    3 ++-
patches/icedtea-demo-swingapplet.patch |   11 +++++++++++

diffs (52 lines):

diff -r 79f28ead8d7b -r fc5078fb4df1 ChangeLog
--- a/ChangeLog	Mon Jan 05 11:42:35 2009 +0000
+++ b/ChangeLog	Tue Jan 06 17:30:41 2009 -0500
@@ -1,3 +1,9 @@ 2009-01-05  Andrew Haley  <aph at redhat.co
+2009-01-06  Omair Majid  <omajid at redhat.com>
+
+	* patches/icedtea-demo-swingapplet.patch: New file.
+	* Makefile.am (ICEDTEA_PATCHES): Apply the above.
+	* HACKING: Document the above.
+
 2009-01-05  Andrew Haley  <aph at redhat.com>
 
 	* Makefile.am (ICEDTEA_PATCHES): Fix bad checkin.
diff -r 79f28ead8d7b -r fc5078fb4df1 HACKING
--- a/HACKING	Mon Jan 05 11:42:35 2009 +0000
+++ b/HACKING	Tue Jan 06 17:30:41 2009 -0500
@@ -79,6 +79,7 @@ The following patches are currently appl
 * icedtea-io_util-overflow.patch: Replace some code to correctly handle overflows. (S6788196)
 * icedtea-cc-interp-jvmti.patch: Disable some JVMTI capabilities which are unsupported or do not work with the C++ interpreter.
 * icedtea-a11y-property-change.patch: Dont fire PropertyChangeEvent if the property hasnt changed.
+* icedtea-demo-swingapplet.patch: Add missing html file needed to run the demo.
 
 The following patches are only applied to OpenJDK6 in IcedTea6:
 
diff -r 79f28ead8d7b -r fc5078fb4df1 Makefile.am
--- a/Makefile.am	Mon Jan 05 11:42:35 2009 +0000
+++ b/Makefile.am	Tue Jan 06 17:30:41 2009 -0500
@@ -688,7 +688,8 @@ endif
 
 ICEDTEA_PATCHES += \
 	$(DISTRIBUTION_PATCHES) \
-	patches/icedtea-a11y-property-change.patch
+	patches/icedtea-a11y-property-change.patch \
+	patches/icedtea-demo-swingapplet.patch
 
 stamps/extract.stamp: stamps/download.stamp
 if OPENJDK_SRC_DIR_FOUND
diff -r 79f28ead8d7b -r fc5078fb4df1 patches/icedtea-demo-swingapplet.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/icedtea-demo-swingapplet.patch	Tue Jan 06 17:30:41 2009 -0500
@@ -0,0 +1,11 @@
+--- openjdk/jdk/make/mkdemo/jfc/SwingApplet/Makefile.orig	2009-01-06 17:07:25.000000000 -0500
++++ openjdk/jdk/make/mkdemo/jfc/SwingApplet/Makefile	2009-01-06 16:47:28.000000000 -0500
+@@ -33,7 +33,7 @@
+ include $(BUILDDIR)/common/Defs.gmk
+ 
+ DEMO_ROOT       = $(SHARE_SRC)/demo/jfc/$(DEMONAME)
+-DEMO_TOPFILES   = ./README.txt
++DEMO_TOPFILES   = ./README.txt ./SwingApplet.html
+ DEMO_MAINCLASS  = $(DEMONAME)
+ DEMO_DESTDIR    = $(DEMODIR)/jfc/$(DEMONAME)
+ 


From doko at ubuntu.com  Tue Jan  6 15:13:37 2009
From: doko at ubuntu.com (Matthias Klose)
Date: Wed, 07 Jan 2009 00:13:37 +0100
Subject: how to build without precompiled headers?
In-Reply-To: <496242E8.10509@sun.com>
References: <49613144.90706@ubuntu.com> <496242E8.10509@sun.com>
Message-ID: <4963E5A1.3060605@ubuntu.com>

Thanks,

please see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38593
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38725

looks like current GCC versions accept invalid code:

"That's really a duplicate of PR38725: The code contains many lines of the form

  goto *dispatch_table[opcode];

where dispatch_table[opcode] is of the type uintptr_t which is a typedef
to unsigned int. Writing

  goto *(void*)dispatch_table[opcode];

instead makes the ICE disappear."


Coleen Phillimore - Sun Microsystems schrieb:
> 
> I tried this on my new 8.10 ubuntu system at home and commenting out
> USE_PRECOMPILED_HEADER didn't use the precompiled header. The file
> _precompiled.incl is still produced but it's empty. I believe you have
> to do a make clean before your gcc.make change is used.
> 
> The version of gcc that I used was very picky about inlined functions
> not being defined in places where the other platforms were happy, so
> there were multiple warnings with this message. I have a patch file that
> resolves this, if you want it.
> Also, on my 8.10 ubuntu, gcc version 4.1.forgot, I got an error building
> fastdebug (server compiler) which I haven't resolved.
> 
> /home/coleenp/hotspot/src/share/vm/libadt/port.hpp:40: error: 'void
> bcopy(const void*, void*, size_t)' redeclared inline without
> 'gnu_inline' attribute
> 
> If you're trying to track down a compiler error building hotspot, try
> getting a preprocessed output file to narrow it down.
> cd linux*/<target>
> make <file that had error>.i
> 
> Hope this helps.
> Coleen
> 
> On 01/04/09 16:59, Matthias Klose wrote:
>> Trying to track down an ICE (internal compiler error), I need to build
>> hotspot
>> without precompiled header files.  There is a macro
>> USE_PRECOMPILED_HEADER
>> defined in openjdk/hotspot/make/*/makefiles/gcc.make, but just
>> removing the
>> conditional around this definition still builds using precompiled
>> header files.
>> How can you build without precompiled header files (even if it's a hack)?
>>
>>   Matthias
>>   



From bugzilla-daemon at icedtea.classpath.org  Tue Jan  6 16:28:43 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 00:28:43 +0000
Subject: [Bug 277] New: zero build with GCC-4.4 ftbfs
Message-ID: <E1LKMHr-0000sj-K4@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=277

           Summary: zero build with GCC-4.4 ftbfs
           Product: IcedTea
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: doko at ubuntu.com


seen when building without precompiled headers

g++-4.4 -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -DPARISC
-DZERO_LIBARCH=\"parisc\" -DPRODUCT -I../generated/adfiles
-I../generated/jvmtifiles
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/asm
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/c1
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/ci
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/classfile
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/code
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/compiler
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/gc_implementation
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/gc_implementation/g1
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/gc_implementation/parNew
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/gc_implementation/parallelScavenge
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/gc_implementation/shared
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/gc_interface
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/interpreter
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/memory
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/oops
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/prims
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/runtime
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/services
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/shark
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/utilities
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/cpu/zero/vm
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/os/linux/vm
-I/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/os_cpu/linux_zero/vm
-I../generated -DHOTSPOT_RELEASE_VERSION="\"14.0-b08\""
-DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"doko\""
-DHOTSPOT_LIB_ARCH=\"parisc\" -DJRE_RELEASE_VERSION="\"1.6.0_0-b14\""
-DHOTSPOT_VM_DISTRO="\"OpenJDK\""  -fPIC -fno-rtti -fno-exceptions -D_REENTRANT
-fcheck-new -g  -pipe -O3 -fno-strict-aliasing  -Wpointer-arith -Wsign-compare 
  -c -o debugInfoRec.o
/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/code/debugInfoRec.cpp
/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:
In static member function 'static void
CppInterpreter::native_entry(methodOopDesc*, intptr_t, Thread*)':
/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:293:
error: 'ThreadStateTransition' has not been declared
/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:300:
error: 'ThreadStateTransition' has not been declared
make[7]: *** [cppInterpreter_zero.o] Error 1
make[7]: *** Waiting for unfinished jobs....
/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/utilities/bitMap.hpp:155:
warning: inline function 'void BitMap::set_bit(size_t)' used but never defined
/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/hotspot/src/share/vm/utilities/bitMap.hpp:155:
warning: inline function 'void BitMap::set_bit(size_t)' used but never defined
make[7]: Leaving directory
`/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/control/build/linux-parisc/hotspot/outputdir/linux_zero_core/product'
make[6]: *** [the_vm] Error 2
make[6]: Leaving directory
`/home/packages/openjdk/openjdk-6-6b14/openjdk-ecj/control/build/linux-parisc/hotspot/outputdir/linux_zero_core/product'
make[5]: *** [productcore] Error 2


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From mvfranz at gmail.com  Tue Jan  6 20:29:12 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Tue, 6 Jan 2009 23:29:12 -0500
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <1231062689.28600.2.camel@localhost.localdomain>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
Message-ID: <fee4d890901062029l3a8215bclcbab2ade3ec22a87@mail.gmail.com>

Christian,

I am having a hard time getting classpath installed (I believe cacaovm
requires it).  I tried to configure classpath:
./configure --disable-jni

but get the following error:
make[2]: *** No rule to make target `../../native/jni/gtk-peer/libgtkpeer.la',
needed by `libjawt.la'.  Stop.

I get the same error if I do not disable jni.

I am using version 0.97.2.

Michael

On Sun, Jan 4, 2009 at 4:51 AM, Christian Thalinger <
christian.thalinger at gmail.com> wrote:

> On Sat, 2009-01-03 at 22:04 +0000, Andrew Haley wrote:
> > Michael Franz wrote:
> >
> > > On Sat, Jan 3, 2009 at 4:05 PM, Andrew Haley <aph at redhat.com> wrote:
> > >
> > >> Andrew Haley wrote:
> > >>> Michael Franz wrote:
> > >>>> I have created the following patches that integrate shark build into
> the
> > >>>> bsd-port repo.  I have not been able to get it to compile, but
> wanted
> > >> these
> > >>>> out there in case they are wrong and causing my problem.
> > >>>>
> > >>>> I am currently stuck on this error:
> > >>> Shark on x86 isn't really ready yet.  I've been debugging it and it's
> > >>> starting to look OK, but it's not stable.
> > >> Actually, I've been working on x86_64.  AFAIAA *nobody* has worked on
> > >> x86.  To be honest, I don't really know why you'd want to: the x86
> > >> Hotspot JIT is very good.
> >
> > > I am not necessarily interested in the using zero/shark on intel (32 or
> > > 64).  I am interested int getting zero/shark integrated into the bsd
> port
> > > for other architectures to use.  Since the bsd-port can only be built
> on
> > > intel (32/64) I figured it would be easier to integrate with a working
> build
> > > than trying to do it on ppc which cannot build icedtea (no valid
> bootstrap
> > > jdk).
> >
> > You might be OK with zero on x86 BSD, but almost certainly not with
> shark.
> > I presume the problem with ppc on BSD is that gcj doesn't work there
> either.
>
> Michael, you can use CACAO or JamVM to bootstrap IcedTea.  For some
> instructions see:
>
> http://c1.complang.tuwien.ac.at/cacaowiki/IcedTea
>
> - Christian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090106/07ea934e/attachment.html 

From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 02:13:49 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 10:13:49 +0000
Subject: [Bug 276] SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKVQ5-0001XC-Ki@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=276





------- Comment #1 from aph at redhat.com  2009-01-07 10:13 -------
We really are going to need a reproducer for this.

If it's as easy as you say, you should be able to provide us with some sample
code.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From doko at ubuntu.com  Wed Jan  7 03:03:45 2009
From: doko at ubuntu.com (doko at ubuntu.com)
Date: Wed, 07 Jan 2009 11:03:45 +0000
Subject: changeset in /hg/icedtea6: 2009-01-07  Matthias Klose  <doko@ubu...
Message-ID: <hg.f8d68d85e72e.1231326225.2873452341184383832@icedtea.classpath.org>

changeset f8d68d85e72e in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=f8d68d85e72e
description:
	2009-01-07  Matthias Klose  <doko at ubuntu.com>

	        * patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch: New, fix
	        build failure with GCC-4.4.
	        * Makefile.am: Apply.
	        * HACKING: Document the above.

diffstat:

4 files changed, 21 insertions(+), 1 deletion(-)
ChangeLog                                              |    7 +++++++
HACKING                                                |    1 +
Makefile.am                                            |    3 ++-
patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch |   11 +++++++++++

diffs (53 lines):

diff -r fc5078fb4df1 -r f8d68d85e72e ChangeLog
--- a/ChangeLog	Tue Jan 06 17:30:41 2009 -0500
+++ b/ChangeLog	Wed Jan 07 12:02:05 2009 +0100
@@ -1,3 +1,10 @@ 2009-01-06  Omair Majid  <omajid at redhat.
+2009-01-07  Matthias Klose  <doko at ubuntu.com>
+
+	* patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch: New, fix
+	build failure with GCC-4.4.
+	* Makefile.am: Apply.
+	* HACKING: Document the above.
+
 2009-01-06  Omair Majid  <omajid at redhat.com>
 
 	* patches/icedtea-demo-swingapplet.patch: New file.
diff -r fc5078fb4df1 -r f8d68d85e72e HACKING
--- a/HACKING	Tue Jan 06 17:30:41 2009 -0500
+++ b/HACKING	Wed Jan 07 12:02:05 2009 +0100
@@ -80,6 +80,7 @@ The following patches are currently appl
 * icedtea-cc-interp-jvmti.patch: Disable some JVMTI capabilities which are unsupported or do not work with the C++ interpreter.
 * icedtea-a11y-property-change.patch: Dont fire PropertyChangeEvent if the property hasnt changed.
 * icedtea-demo-swingapplet.patch: Add missing html file needed to run the demo.
+* icedtea-hotspot-dispatch.patch: Fix build failure with GCC-4.4 (PR 38725).
 
 The following patches are only applied to OpenJDK6 in IcedTea6:
 
diff -r fc5078fb4df1 -r f8d68d85e72e Makefile.am
--- a/Makefile.am	Tue Jan 06 17:30:41 2009 -0500
+++ b/Makefile.am	Wed Jan 07 12:02:05 2009 +0100
@@ -649,7 +649,8 @@ ICEDTEA_PATCHES += \
 ICEDTEA_PATCHES += \
 	patches/icedtea-format-warnings.patch \
 	patches/icedtea-fortify-source.patch \
-	patches/hotspot/$(HSBUILD)/icedtea-sparc-buildfixes.patch
+	patches/hotspot/$(HSBUILD)/icedtea-sparc-buildfixes.patch \
+	patches/hotspot/$(HSBUILD)/icedtea-hotspot-dispatch.patch
 endif
 
 if !WITH_ALT_HSBUILD
diff -r fc5078fb4df1 -r f8d68d85e72e patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch	Wed Jan 07 12:02:05 2009 +0100
@@ -0,0 +1,11 @@
+--- openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp.old	2009-01-06 16:16:57.000000000 -0700
++++ openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp	2009-01-06 16:17:53.000000000 -0700
+@@ -163,7 +163,7 @@
+ #ifdef USELABELS
+ // Have to do this dispatch this way in C++ because otherwise gcc complains about crossing an
+ // initialization (which is is the initialization of the table pointer...)
+-#define DISPATCH(opcode) goto *dispatch_table[opcode]
++#define DISPATCH(opcode) goto *(void *)dispatch_table[opcode]
+ #define CONTINUE {                              \
+         opcode = *pc;                           \
+         DO_UPDATE_INSTRUCTION_COUNT(opcode);    \


From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 03:06:38 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 11:06:38 +0000
Subject: [Bug 277] zero build with ftbfs when building without precompiled
	headers
Message-ID: <E1LKWFC-0001Zp-6r@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=277


doko at ubuntu.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|zero build with GCC-4.4     |zero build with ftbfs when
                   |ftbfs                       |building without precompiled
                   |                            |headers




------- Comment #1 from doko at ubuntu.com  2009-01-07 11:06 -------
doesn't seem to be special with 4.4, building without the precompiled headers
shows this problem.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 03:21:57 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 11:21:57 +0000
Subject: [Bug 277] zero fails to build from source when building without
	precompiled headers
Message-ID: <E1LKWU1-0001as-Vl@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=277


aph at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|zero build with ftbfs when  |zero fails to build from
                   |building without precompiled|source when building without
                   |headers                     |precompiled headers




-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From christian.thalinger at gmail.com  Wed Jan  7 05:35:30 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Wed, 07 Jan 2009 14:35:30 +0100
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <fee4d890901062029l3a8215bclcbab2ade3ec22a87@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
	<fee4d890901062029l3a8215bclcbab2ade3ec22a87@mail.gmail.com>
Message-ID: <1231335330.16494.11.camel@localhost.localdomain>

On Tue, 2009-01-06 at 23:29 -0500, Michael Franz wrote:
> Christian,
> 
> I am having a hard time getting classpath installed (I believe cacaovm
> requires it).  I tried to configure classpath:
> ./configure --disable-jni
> 
> but get the following error:
> make[2]: *** No rule to make target
> `../../native/jni/gtk-peer/libgtkpeer.la', needed by `libjawt.la'.
> Stop.
> 
> I get the same error if I do not disable jni.  
> 
> I am using version 0.97.2.

Hmm, maybe --disable-jni is broken.  Anyway, it's better if you just
disable what does not build:

--disable-gtk-peer --disable-plugin

Maybe you need to disable more stuff, but for now try these two.

- Christian



From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 06:05:56 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 14:05:56 +0000
Subject: [Bug 278] New: SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKZ2i-0001kE-Kp@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=278

           Summary: SIGSEGV in 64 bit JDK 1.6 when using JNI, and both
                    library and Java app are threaded
           Product: IcedTea
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: bruce.roscherr at citi.com


I am getting a SIGSEGV from the JVM when I run an app that uses a large amount
of memory, calls a native library that is threaded, and the java app
subsequently uses threads. I hope someone is in the position to test this bug,
as it seems to need a lot of moving parts.

I have had the same bug when using a library from Intel, and from another
vendor, MOSEK. In both cases I was able to reproduce the bug with minor tweaks
to example code supplied by each vendor, hopefully thereby removing user error.
I ran both of these on RedHat (glibc-2.5 based) and Ubuntu (glibc-2.7) for
different JDK 1.6 releases, always with the same result.


The basic structure of the app that causes the crash is this:
1. Create a few large arrays, 4 arrays with 10 million elements each will do
the trick, and fill them with random numbers, call them A, B, C, D
2. Call a function that uses JNI to call a threaded C function, doesnn't need
to involve A, B, C or D
3. Spawn a couple of Java threads and manipulate the arrays you created
initially, do dumb things like A=B+C, D=B+C.

This should crash your 64 bit JVM. It always crashes after the call to the
native library while working in the Java threads.

Here is a crash log from one of these failures:
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000382c80dd4d, pid=11407, tid=1084881216
#
# Java VM: OpenJDK 64-Bit Server VM (1.6.0_0-b11 mixed mode linux-amd64)
# Problematic frame:
# C  [libpthread.so.0+0xdd4d]  raise+0x2d
#
# If you would like to submit a bug report, please visit:
#   http://icedtea.classpath.org/bugzilla
#

---------------  T H R E A D  ---------------

Current thread is native thread

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=-6 (FPE_FLTOVF),
si_addr=0x000164a800002c8f

Registers:
RAX=0x0000000000000000, RBX=0x0000000000000000, RCX=0xffffffffffffffff,
RDX=0x000000000000000b
RSP=0x0000000040a9f068, RBP=0x0000000040a9f130, RSI=0x0000000000002ca3,
RDI=0x0000000000002c8f
R8 =0x0000000003347050, R9 =0x0000000000000001, R10=0x0000000000000000,
R11=0x0000000000000202
R12=0x0000000000000000, R13=0x0000000000000000, R14=0x00002aabb59ab700,
R15=0x0000000000000020
RIP=0x000000382c80dd4d, EFL=0x0000000000000202, CSGSFS=0x0000000000000033,
ERR=0x0000000000000000
  TRAPNO=0x0000000000000000

Top of Stack: (sp=0x0000000040a9f068)
0x0000000040a9f068:   00002aabb589aa21 fffffffe7fffffff
0x0000000040a9f078:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f088:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f098:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0a8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0b8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0c8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0d8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0e8:   ffffffffffffffff 0000000000000000
0x0000000040a9f0f8:   0000000040aa0000 0000000000001000
0x0000000040a9f108:   0000000000000000 000000004963b8f2
0x0000000040a9f118:   000000001ced22d8 000000004963b8f2
0x0000000040a9f128:   000000000005e117 0000000000000000
0x0000000040a9f138:   000000382c8062f7 0000000000000000
0x0000000040a9f148:   0000000040a9f940 0000000000000000
0x0000000040a9f158:   0000000000000000 0000000000000000
0x0000000040a9f168:   0000000000000000 0000000000000000
0x0000000040a9f178:   0000000000000000 0000000000000000
0x0000000040a9f188:   0000000000000000 0000000000000000
0x0000000040a9f198:   0000000000000000 0000000000000000
0x0000000040a9f1a8:   0000000000000000 0000000000000000
0x0000000040a9f1b8:   0000000000000000 0000000000000000
0x0000000040a9f1c8:   0000000000000000 0000000040a9f940
0x0000000040a9f1d8:   5a917365255b1a74 0000000000000000
0x0000000040a9f1e8:   0000000000000000 0000000040aa0000
0x0000000040a9f1f8:   0000000000001000 5a91736565f2eb34
0x0000000040a9f208:   5a91735d09db78c9 0000000000000000
0x0000000040a9f218:   0000000000000000 0000000000000000
0x0000000040a9f228:   0000000000000000 0000000000000000
0x0000000040a9f238:   0000000000000000 0000000000000000
0x0000000040a9f248:   0000000040a9f940 0000000000000000
0x0000000040a9f258:   000000382bcd1e3d 0000000000000000 

Instructions: (pc=0x000000382c80dd4d)
0x000000382c80dd3d:   b8 ea 00 00 00 48 63 d1 48 63 f6 48 63 ff 0f 05
0x000000382c80dd4d:   48 3d 00 f0 ff ff 89 c2 77 03 89 d0 c3 48 8b 05 

Stack: [0x0000000040a8f000,0x0000000040aa0000],  sp=0x0000000040a9f068,  free
space=64k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libpthread.so.0+0xdd4d]  raise+0x2d


---------------  P R O C E S S  ---------------

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 PSYoungGen      total 305856K, used 131463K [0x00002aab5e4d0000,
0x00002aab73a20000, 0x00002aabb3a20000)
  eden space 262208K, 50% used
[0x00002aab5e4d0000,0x00002aab66531f88,0x00002aab6e4e0000)
  from space 43648K, 0% used
[0x00002aab70f80000,0x00002aab70f80000,0x00002aab73a20000)
  to   space 43648K, 0% used
[0x00002aab6e4e0000,0x00002aab6e4e0000,0x00002aab70f80000)
 PSOldGen        total 699072K, used 0K [0x00002aaab3a20000,
0x00002aaade4d0000, 0x00002aab5e4d0000)
  object space 699072K, 0% used
[0x00002aaab3a20000,0x00002aaab3a20000,0x00002aaade4d0000)
 PSPermGen       total 21248K, used 3417K [0x00002aaaae620000,
0x00002aaaafae0000, 0x00002aaab3a20000)
  object space 21248K, 16% used
[0x00002aaaae620000,0x00002aaaae9765e0,0x00002aaaafae0000)

Dynamic libraries:
00400000-00409000 r-xp 00000000 08:02 3521722                           
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java
00608000-0060a000 rw-p 00008000 08:02 3521722                           
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java
03188000-0345b000 rw-p 03188000 00:00 0 
40186000-40187000 ---p 40186000 00:00 0 
40187000-40287000 rwxp 40187000 00:00 0 
40287000-40288000 ---p 40287000 00:00 0 
40288000-40388000 rwxp 40288000 00:00 0 
40388000-40389000 ---p 40388000 00:00 0 
40389000-40489000 rwxp 40389000 00:00 0 
40489000-4048a000 ---p 40489000 00:00 0 
4048a000-4058a000 rwxp 4048a000 00:00 0 
4058a000-4058b000 ---p 4058a000 00:00 0 
4058b000-4068b000 rwxp 4058b000 00:00 0 
4068b000-4068c000 ---p 4068b000 00:00 0 
4068c000-4078c000 rwxp 4068c000 00:00 0 
4078c000-4078d000 ---p 4078c000 00:00 0 
4078d000-4088d000 rwxp 4078d000 00:00 0 
4088d000-4088e000 ---p 4088d000 00:00 0 
4088e000-4098e000 rwxp 4088e000 00:00 0 
4098e000-4098f000 ---p 4098e000 00:00 0 
4098f000-40a8f000 rwxp 4098f000 00:00 0 
40a8f000-40a90000 ---p 40a8f000 00:00 0 
40a90000-40aa0000 rwxp 40a90000 00:00 0 
40aa0000-40aa1000 ---p 40aa0000 00:00 0 
40aa1000-40e99000 rwxp 40aa1000 00:00 0 
40f10000-40f13000 ---p 40f10000 00:00 0 
40f13000-41011000 rwxp 40f13000 00:00 0 
41011000-41014000 ---p 41011000 00:00 0 
41014000-41112000 rwxp 41014000 00:00 0 
41112000-41115000 ---p 41112000 00:00 0 
41115000-41213000 rwxp 41115000 00:00 0 
41213000-41216000 ---p 41213000 00:00 0 
41216000-41314000 rwxp 41216000 00:00 0 
41314000-41317000 ---p 41314000 00:00 0 
41317000-41415000 rwxp 41317000 00:00 0 
41415000-41418000 ---p 41415000 00:00 0 
41418000-41516000 rwxp 41418000 00:00 0 
41516000-41519000 ---p 41516000 00:00 0 
41519000-41617000 rwxp 41519000 00:00 0 
41617000-41618000 ---p 41617000 00:00 0 
41618000-41718000 rwxp 41618000 00:00 0 
41718000-41719000 ---p 41718000 00:00 0 
41719000-42119000 rwxp 41719000 00:00 0 
42119000-4211c000 ---p 42119000 00:00 0 
4211c000-4221a000 rwxp 4211c000 00:00 0 
4221a000-4221b000 ---p 4221a000 00:00 0 
4221b000-42613000 rwxp 4221b000 00:00 0 
42613000-42614000 ---p 42613000 00:00 0 
42614000-42a0c000 rwxp 42614000 00:00 0 
42a0c000-42a0d000 ---p 42a0c000 00:00 0 
42a0d000-42e06000 rwxp 42a0d000 00:00 0 
42e06000-42e07000 ---p 42e06000 00:00 0 
42e07000-43200000 rwxp 42e07000 00:00 0 
43200000-43201000 ---p 43200000 00:00 0 
43201000-435fa000 rwxp 43201000 00:00 0 
435fa000-435fb000 ---p 435fa000 00:00 0 
435fb000-439f4000 rwxp 435fb000 00:00 0 
439f4000-439f7000 ---p 439f4000 00:00 0 
439f7000-43af5000 rwxp 439f7000 00:00 0 
43af5000-43af8000 ---p 43af5000 00:00 0 
43af8000-43bf6000 rwxp 43af8000 00:00 0 
382b800000-382b81a000 r-xp 00000000 08:02 2312950                       
/lib64/ld-2.5.so
382ba1a000-382ba1b000 r--p 0001a000 08:02 2312950                       
/lib64/ld-2.5.so
382ba1b000-382ba1c000 rw-p 0001b000 08:02 2312950                       
/lib64/ld-2.5.so
382bc00000-382bd4a000 r-xp 00000000 08:02 2312952                       
/lib64/libc-2.5.so
382bd4a000-382bf4a000 ---p 0014a000 08:02 2312952                       
/lib64/libc-2.5.so
382bf4a000-382bf4e000 r--p 0014a000 08:02 2312952                       
/lib64/libc-2.5.so
382bf4e000-382bf4f000 rw-p 0014e000 08:02 2312952                       
/lib64/libc-2.5.so
382bf4f000-382bf54000 rw-p 382bf4f000 00:00 0 
382c000000-382c002000 r-xp 00000000 08:02 1661404                       
/lib64/libdl-2.5.so
382c002000-382c202000 ---p 00002000 08:02 1661404                       
/lib64/libdl-2.5.so
382c202000-382c203000 r--p 00002000 08:02 1661404                       
/lib64/libdl-2.5.so
382c203000-382c204000 rw-p 00003000 08:02 1661404                       
/lib64/libdl-2.5.so
382c400000-382c404000 r-xp 00000000 08:02 3528267                       
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so
382c404000-382c603000 ---p 00004000 08:02 3528267                       
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so
382c603000-382c604000 rw-p 00003000 08:02 3528267                       
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so
382c800000-382c815000 r-xp 00000000 08:02 1661429                       
/lib64/libpthread-2.5.so
382c815000-382ca14000 ---p 00015000 08:02 1661429                       
/lib64/libpthread-2.5.so
382ca14000-382ca15000 r--p 00014000 08:02 1661429                       
/lib64/libpthread-2.5.so
382ca15000-382ca16000 rw-p 00015000 08:02 1661429                       
/lib64/libpthread-2.5.so
382ca16000-382ca1a000 rw-p 382ca16000 00:00 0 
382cc00000-382cc14000 r-xp 00000000 08:02 1883612                       
/usr/lib64/libz.so.1.2.3
382cc14000-382ce13000 ---p 00014000 08:02 1883612                       
/usr/lib64/libz.so.1.2.3
382ce13000-382ce14000 rw-p 00013000 08:02 1883612                       
/usr/lib64/libz.so.1.2.3
3830400000-3830407000 r-xp 00000000 08:02 2312958                       
/lib64/librt-2.5.so
3830407000-3830607000 ---p 00007000 08:02 2312958                       
/lib64/librt-2.5.so
3830607000-3830608000 r--p 00007000 08:02 2312958                       
/lib64/librt-2.5.so
3830608000-3830609000 rw-p 00008000 08:02 2312958                       
/lib64/librt-2.5.so
3831c00000-3831c0d000 r-xp 00000000 08:02 1661403                       
/lib64/libgcc_s-4.1.2-20080102.so.1
3831c0d000-3831e0d000 ---p 0000d000 08:02 1661403                       
/lib64/libgcc_s-4.1.2-20080102.so.1
3831e0d000-3831e0e000 rw-p 0000d000 08:02 1661403                       
/lib64/libgcc_s-4.1.2-20080102.so.1
3835e00000-3835e15000 r-xp 00000000 08:02 2313092                       
/lib64/libnsl-2.5.so
3835e15000-3836014000 ---p 00015000 08:02 2313092                       
/lib64/libnsl-2.5.so
3836014000-3836015000 r--p 00014000 08:02 2313092                       
/lib64/libnsl-2.5.so
3836015000-3836016000 rw-p 00015000 08:02 2313092                       
/lib64/libnsl-2.5.so
3836016000-3836018000 rw-p 3836016000 00:00 0 
2aaaaaaab000-2aaaaaad3000 rw-p 2aaaaaaab000 00:00 0 
2aaaaaad5000-2aaaaaad6000 r--p 2aaaaaad5000 00:00 0 
2aaaaaad6000-2aaaaaad7000 rwxp 2aaaaaad6000 00:00 0 
2aaaaaad7000-2aaaaaadf000 r-xp 00000000 08:02 3521163                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libhpi.so
2aaaaaadf000-2aaaaacde000 ---p 00008000 08:02 3521163                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libhpi.so
2aaaaacde000-2aaaaacdf000 rw-p 00007000 08:02 3521163                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libhpi.so
2aaaaacdf000-2aaaaace0000 rw-p 2aaaaacdf000 00:00 0 
2aaaaace0000-2aaaaace8000 rw-s 00000000 00:14 22856                     
/tmp/hsperfdata_brucer/11407
2aaaaad07000-2aaaaad11000 r-xp 00000000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaad11000-2aaaaaf10000 ---p 0000a000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaaf10000-2aaaaaf11000 r--p 00009000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaaf11000-2aaaaaf12000 rw-p 0000a000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaaf12000-2aaaaaf20000 r-xp 00000000 08:02 3521160                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libverify.so
2aaaaaf20000-2aaaab11f000 ---p 0000e000 08:02 3521160                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libverify.so
2aaaab11f000-2aaaab121000 rw-p 0000d000 08:02 3521160                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libverify.so
2aaaab121000-2aaaab14c000 r-xp 00000000 08:02 3521142                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
2aaaab14c000-2aaaab34c000 ---p 0002b000 08:02 3521142                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
2aaaab34c000-2aaaab350000 rw-p 0002b000 08:02 3521142                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
2aaaab350000-2aaaab357000 r-xp 00000000 08:02 3521161                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libzip.so
2aaaab357000-2aaaab556000 ---p 00007000 08:02 3521161                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libzip.so
2aaaab556000-2aaaab557000 rw-p 00006000 08:02 3521161                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libzip.so
2aaaab557000-2aaaab7c7000 rwxp 2aaaab557000 00:00 0 
2aaaab7c7000-2aaaae557000 rwxp 2aaaab7c7000 00:00 0 
2aaaae557000-2aaaae561000 rwxp 2aaaae557000 00:00 0 
2aaaae561000-2aaaae617000 rwxp 2aaaae561000 00:00 0 
2aaaae620000-2aaaafae0000 rwxp 2aaaae620000 00:00 0 
2aaaafae0000-2aaab3a20000 rwxp 2aaaafae0000 00:00 0 
2aaab3a20000-2aaade4d0000 rwxp 2aaab3a20000 00:00 0 
2aaade4d0000-2aab5e4d0000 rwxp 2aaade4d0000 00:00 0 
2aab5e4d0000-2aab73a20000 rwxp 2aab5e4d0000 00:00 0 
2aab73a20000-2aabb3a20000 rwxp 2aab73a20000 00:00 0 
2aabb3a20000-2aabb3a2b000 rwxp 2aabb3a20000 00:00 0 
2aabb3a2b000-2aabb3a4a000 rwxp 2aabb3a2b000 00:00 0 
2aabb3a4a000-2aabb3ba0000 rwxp 2aabb3a4a000 00:00 0 
2aabb3ba0000-2aabb3f9f000 rwxp 2aabb3ba0000 00:00 0 
2aabb3f9f000-2aabb404a000 rwxp 2aabb3f9f000 00:00 0 
2aabb404a000-2aabb424a000 rwxp 2aabb404a000 00:00 0 
2aabb424a000-2aabb43a1000 rwxp 2aabb424a000 00:00 0 
2aabb43a1000-2aabb47a1000 rwxp 2aabb43a1000 00:00 0 
2aabb47a1000-2aabb47ac000 rwxp 2aabb47a1000 00:00 0 
2aabb47ac000-2aabb47cb000 rwxp 2aabb47ac000 00:00 0 
2aabb47cb000-2aabb4969000 r--s 01803000 08:02 3521228                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
2aabb4969000-2aabb4ac7000 rw-p 2aabb4969000 00:00 0 
2aabb4ac7000-2aabb4ad0000 r--s 00060000 08:02 3521184                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/ext/gnome-java-bridge.jar
2aabb4ad0000-2aabb4ad2000 r--s 0000b000 08:05 68059640                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/mosek.jar
2aabb4ad2000-2aabb4ad5000 r--s 00039000 08:02 3521213                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/jsse.jar
2aabb4ad5000-2aabb4b25000 r-xp 00000000 08:05 68059648                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosekjava5_0.so
2aabb4b25000-2aabb4c25000 ---p 00050000 08:05 68059648                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosekjava5_0.so
2aabb4c25000-2aabb4c26000 rw-p 00050000 08:05 68059648                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosekjava5_0.so
2aabb4c26000-2aabb528c000 r-xp 00000000 08:05 68059641                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosek64.so.5.0
2aabb528c000-2aabb538b000 ---p 00666000 08:05 68059641                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosek64.so.5.0
2aabb538b000-2aabb53bd000 rw-p 00665000 08:05 68059641                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosek64.so.5.0
2aabb53bd000-2aabb53c0000 rw-p 2aabb53bd000 00:00 0 
2aabb53c0000-2aabb53fe000 r-xp 00000000 08:05 68059639                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libirc.so
2aabb53fe000-2aabb54fd000 ---p 0003e000 08:05 68059639                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libirc.so
2aabb54fd000-2aabb54ff000 rw-p 0003d000 08:05 68059639                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libirc.so
2aabb54ff000-2aabb5500000 rw-p 2aabb54ff000 00:00 0 
2aabb5500000-2aabb5765000 r-xp 00000000 08:05 68059657                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libimf.so
2aabb5765000-2aabb5864000 ---p 00265000 08:05 68059657                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libimf.so
2aabb5864000-2aabb5869000 rw-p 00264000 08:05 68059657                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libimf.so
2aabb5869000-2aabb58a9000 r-xp 00000000 08:05 68059643                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libguide.so
2aabb58a9000-2aabb59a8000 ---p 00040000 08:05 68059643                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libguide.so
2aabb59a8000-2aabb59ab000 rw-p 0003f000 08:05 68059643                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libguide.so
2aabb59ab000-2aabb59b1000 rw-p 2aabb59ab000 00:00 0 
2aabb59b1000-2aabb59d1000 r-xp 00000000 08:05 68059635                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libsvml.so
2aabb59d1000-2aabb5ad0000 ---p 00020000 08:05 68059635                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libsvml.so
2aabb5ad0000-2aabb5af4000 rw-p 0001f000 08:05 68059635                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libsvml.so
2aabb8000000-2aabb8021000 rw-p 2aabb8000000 00:00 0 
2aabb8021000-2aabbc000000 ---p 2aabb8021000 00:00 0 
2ba5d7d82000-2ba5d7d84000 rw-p 2ba5d7d82000 00:00 0 
2ba5d7dab000-2ba5d7dae000 rw-p 2ba5d7dab000 00:00 0 
2ba5d7dae000-2ba5d84ea000 r-xp 00000000 08:02 3521167                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
2ba5d84ea000-2ba5d86ea000 ---p 0073c000 08:02 3521167                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
2ba5d86ea000-2ba5d8762000 rw-p 0073c000 08:02 3521167                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
2ba5d8762000-2ba5d879b000 rw-p 2ba5d8762000 00:00 0 
2ba5d87c2000-2ba5d8844000 r-xp 00000000 08:02 1661430                   
/lib64/libm-2.5.so
2ba5d8844000-2ba5d8a43000 ---p 00082000 08:02 1661430                   
/lib64/libm-2.5.so
2ba5d8a43000-2ba5d8a44000 r--p 00081000 08:02 1661430                   
/lib64/libm-2.5.so
2ba5d8a44000-2ba5d8a45000 rw-p 00082000 08:02 1661430                   
/lib64/libm-2.5.so
7fffd2d12000-7fffd2d25000 rwxp 7fffd2d12000 00:00 0                     
[stack]
7fffd2d25000-7fffd2d28000 rw-p 7fffd2d25000 00:00 0 
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]

VM Arguments:
jvm_args: -Xms1024m -Xmx4096m 
java_command: qcqo1.qcqo1
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk.x86_64
PATH=/data2/r-project/bin:/home/brucer/bin:/work/loc0/prod/bbin:/work/loc2/prod/bbin:/work/loc2/prod/pbin:/work/loc2/prod/pybin:/work/loc2/prod/bin:/work/loc1/prod/bin:/data1/bruce/gcc/bin:/data2/r-project/bin:/home/brucer/bin:/work/loc0/prod/bbin:/work/loc2/prod/bbin:/work/loc2/prod/pbin:/work/loc2/prod/pybin:/work/loc2/prod/bin:/work/loc1/prod/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/brucer/bin:/work/loc2/prod/bin/hcsv:/work/loc0/prod/mod/utils:/home/brucer/bin:/home/brucer/bin:/work/loc2/prod/bin/hcsv:/work/loc0/prod/mod/utils
USERNAME=brucer
LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin:/data1/bruce/lib:/data2/r-project/lib64/R/lib:/data2/r-project/bin:/work/loc1/lib64:/work/opt/lib/wombat408:/usr/lib/oracle/10.2.0.4/client64/lib
SHELL=/bin/bash
DISPLAY=:0.0

Signal Handlers:
SIGSEGV: [libjvm.so+0x618cc0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x618cc0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGXFSZ: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x4e0340], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004


---------------  S Y S T E M  ---------------

OS:Red Hat Enterprise Linux Server release 5.2 (Tikanga)

uname:Linux 2.6.18-92.1.22.el5 #1 SMP Fri Dec 5 09:28:22 EST 2008 x86_64
libc:glibc 2.5 NPTL 2.5 
rlimit: STACK 10240k, CORE infinity, NPROC 135168, NOFILE 1024, AS infinity
load average:0.39 0.48 0.36

CPU:total 8 (4 cores per cpu, 1 threads per core) family 6 model 7 stepping 6,
cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3

Memory: 4k page, physical 16312852k(6475052k free), swap 8546540k(1728304k
free)

vm_info: OpenJDK 64-Bit Server VM (1.6.0_0-b11) for linux-amd64 JRE
(1.6.0_0-b11), built on Jul 25 2008 06:43:15 by "mockbuild" with gcc 4.1.2
20071124 (Red Hat 4.1.2-42)

time: Tue Jan  6 15:02:58 2009
elapsed time: 4 seconds


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 06:08:01 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 14:08:01 +0000
Subject: [Bug 278] SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKZ4j-0001kP-8Z@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=278


bruce.roscherr at citi.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |279
              nThis|                            |




-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 06:08:01 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 14:08:01 +0000
Subject: [Bug 279] New: SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKZ4j-0001kN-40@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=279

           Summary: SIGSEGV in 64 bit JDK 1.6 when using JNI, and both
                    library and Java app are threaded
           Product: IcedTea
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: bruce.roscherr at citi.com
 BugsThisDependsOn: 278


Sorry, don't know how I posted this again.

+++ This bug was initially created as a clone of Bug #278 +++

I am getting a SIGSEGV from the JVM when I run an app that uses a large amount
of memory, calls a native library that is threaded, and the java app
subsequently uses threads. I hope someone is in the position to test this bug,
as it seems to need a lot of moving parts.

I have had the same bug when using a library from Intel, and from another
vendor, MOSEK. In both cases I was able to reproduce the bug with minor tweaks
to example code supplied by each vendor, hopefully thereby removing user error.
I ran both of these on RedHat (glibc-2.5 based) and Ubuntu (glibc-2.7) for
different JDK 1.6 releases, always with the same result.


The basic structure of the app that causes the crash is this:
1. Create a few large arrays, 4 arrays with 10 million elements each will do
the trick, and fill them with random numbers, call them A, B, C, D
2. Call a function that uses JNI to call a threaded C function, doesnn't need
to involve A, B, C or D
3. Spawn a couple of Java threads and manipulate the arrays you created
initially, do dumb things like A=B+C, D=B+C.

This should crash your 64 bit JVM. It always crashes after the call to the
native library while working in the Java threads.

Here is a crash log from one of these failures:
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000382c80dd4d, pid=11407, tid=1084881216
#
# Java VM: OpenJDK 64-Bit Server VM (1.6.0_0-b11 mixed mode linux-amd64)
# Problematic frame:
# C  [libpthread.so.0+0xdd4d]  raise+0x2d
#
# If you would like to submit a bug report, please visit:
#   http://icedtea.classpath.org/bugzilla
#

---------------  T H R E A D  ---------------

Current thread is native thread

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=-6 (FPE_FLTOVF),
si_addr=0x000164a800002c8f

Registers:
RAX=0x0000000000000000, RBX=0x0000000000000000, RCX=0xffffffffffffffff,
RDX=0x000000000000000b
RSP=0x0000000040a9f068, RBP=0x0000000040a9f130, RSI=0x0000000000002ca3,
RDI=0x0000000000002c8f
R8 =0x0000000003347050, R9 =0x0000000000000001, R10=0x0000000000000000,
R11=0x0000000000000202
R12=0x0000000000000000, R13=0x0000000000000000, R14=0x00002aabb59ab700,
R15=0x0000000000000020
RIP=0x000000382c80dd4d, EFL=0x0000000000000202, CSGSFS=0x0000000000000033,
ERR=0x0000000000000000
  TRAPNO=0x0000000000000000

Top of Stack: (sp=0x0000000040a9f068)
0x0000000040a9f068:   00002aabb589aa21 fffffffe7fffffff
0x0000000040a9f078:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f088:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f098:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0a8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0b8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0c8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0d8:   ffffffffffffffff ffffffffffffffff
0x0000000040a9f0e8:   ffffffffffffffff 0000000000000000
0x0000000040a9f0f8:   0000000040aa0000 0000000000001000
0x0000000040a9f108:   0000000000000000 000000004963b8f2
0x0000000040a9f118:   000000001ced22d8 000000004963b8f2
0x0000000040a9f128:   000000000005e117 0000000000000000
0x0000000040a9f138:   000000382c8062f7 0000000000000000
0x0000000040a9f148:   0000000040a9f940 0000000000000000
0x0000000040a9f158:   0000000000000000 0000000000000000
0x0000000040a9f168:   0000000000000000 0000000000000000
0x0000000040a9f178:   0000000000000000 0000000000000000
0x0000000040a9f188:   0000000000000000 0000000000000000
0x0000000040a9f198:   0000000000000000 0000000000000000
0x0000000040a9f1a8:   0000000000000000 0000000000000000
0x0000000040a9f1b8:   0000000000000000 0000000000000000
0x0000000040a9f1c8:   0000000000000000 0000000040a9f940
0x0000000040a9f1d8:   5a917365255b1a74 0000000000000000
0x0000000040a9f1e8:   0000000000000000 0000000040aa0000
0x0000000040a9f1f8:   0000000000001000 5a91736565f2eb34
0x0000000040a9f208:   5a91735d09db78c9 0000000000000000
0x0000000040a9f218:   0000000000000000 0000000000000000
0x0000000040a9f228:   0000000000000000 0000000000000000
0x0000000040a9f238:   0000000000000000 0000000000000000
0x0000000040a9f248:   0000000040a9f940 0000000000000000
0x0000000040a9f258:   000000382bcd1e3d 0000000000000000 

Instructions: (pc=0x000000382c80dd4d)
0x000000382c80dd3d:   b8 ea 00 00 00 48 63 d1 48 63 f6 48 63 ff 0f 05
0x000000382c80dd4d:   48 3d 00 f0 ff ff 89 c2 77 03 89 d0 c3 48 8b 05 

Stack: [0x0000000040a8f000,0x0000000040aa0000],  sp=0x0000000040a9f068,  free
space=64k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libpthread.so.0+0xdd4d]  raise+0x2d


---------------  P R O C E S S  ---------------

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 PSYoungGen      total 305856K, used 131463K [0x00002aab5e4d0000,
0x00002aab73a20000, 0x00002aabb3a20000)
  eden space 262208K, 50% used
[0x00002aab5e4d0000,0x00002aab66531f88,0x00002aab6e4e0000)
  from space 43648K, 0% used
[0x00002aab70f80000,0x00002aab70f80000,0x00002aab73a20000)
  to   space 43648K, 0% used
[0x00002aab6e4e0000,0x00002aab6e4e0000,0x00002aab70f80000)
 PSOldGen        total 699072K, used 0K [0x00002aaab3a20000,
0x00002aaade4d0000, 0x00002aab5e4d0000)
  object space 699072K, 0% used
[0x00002aaab3a20000,0x00002aaab3a20000,0x00002aaade4d0000)
 PSPermGen       total 21248K, used 3417K [0x00002aaaae620000,
0x00002aaaafae0000, 0x00002aaab3a20000)
  object space 21248K, 16% used
[0x00002aaaae620000,0x00002aaaae9765e0,0x00002aaaafae0000)

Dynamic libraries:
00400000-00409000 r-xp 00000000 08:02 3521722                           
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java
00608000-0060a000 rw-p 00008000 08:02 3521722                           
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java
03188000-0345b000 rw-p 03188000 00:00 0 
40186000-40187000 ---p 40186000 00:00 0 
40187000-40287000 rwxp 40187000 00:00 0 
40287000-40288000 ---p 40287000 00:00 0 
40288000-40388000 rwxp 40288000 00:00 0 
40388000-40389000 ---p 40388000 00:00 0 
40389000-40489000 rwxp 40389000 00:00 0 
40489000-4048a000 ---p 40489000 00:00 0 
4048a000-4058a000 rwxp 4048a000 00:00 0 
4058a000-4058b000 ---p 4058a000 00:00 0 
4058b000-4068b000 rwxp 4058b000 00:00 0 
4068b000-4068c000 ---p 4068b000 00:00 0 
4068c000-4078c000 rwxp 4068c000 00:00 0 
4078c000-4078d000 ---p 4078c000 00:00 0 
4078d000-4088d000 rwxp 4078d000 00:00 0 
4088d000-4088e000 ---p 4088d000 00:00 0 
4088e000-4098e000 rwxp 4088e000 00:00 0 
4098e000-4098f000 ---p 4098e000 00:00 0 
4098f000-40a8f000 rwxp 4098f000 00:00 0 
40a8f000-40a90000 ---p 40a8f000 00:00 0 
40a90000-40aa0000 rwxp 40a90000 00:00 0 
40aa0000-40aa1000 ---p 40aa0000 00:00 0 
40aa1000-40e99000 rwxp 40aa1000 00:00 0 
40f10000-40f13000 ---p 40f10000 00:00 0 
40f13000-41011000 rwxp 40f13000 00:00 0 
41011000-41014000 ---p 41011000 00:00 0 
41014000-41112000 rwxp 41014000 00:00 0 
41112000-41115000 ---p 41112000 00:00 0 
41115000-41213000 rwxp 41115000 00:00 0 
41213000-41216000 ---p 41213000 00:00 0 
41216000-41314000 rwxp 41216000 00:00 0 
41314000-41317000 ---p 41314000 00:00 0 
41317000-41415000 rwxp 41317000 00:00 0 
41415000-41418000 ---p 41415000 00:00 0 
41418000-41516000 rwxp 41418000 00:00 0 
41516000-41519000 ---p 41516000 00:00 0 
41519000-41617000 rwxp 41519000 00:00 0 
41617000-41618000 ---p 41617000 00:00 0 
41618000-41718000 rwxp 41618000 00:00 0 
41718000-41719000 ---p 41718000 00:00 0 
41719000-42119000 rwxp 41719000 00:00 0 
42119000-4211c000 ---p 42119000 00:00 0 
4211c000-4221a000 rwxp 4211c000 00:00 0 
4221a000-4221b000 ---p 4221a000 00:00 0 
4221b000-42613000 rwxp 4221b000 00:00 0 
42613000-42614000 ---p 42613000 00:00 0 
42614000-42a0c000 rwxp 42614000 00:00 0 
42a0c000-42a0d000 ---p 42a0c000 00:00 0 
42a0d000-42e06000 rwxp 42a0d000 00:00 0 
42e06000-42e07000 ---p 42e06000 00:00 0 
42e07000-43200000 rwxp 42e07000 00:00 0 
43200000-43201000 ---p 43200000 00:00 0 
43201000-435fa000 rwxp 43201000 00:00 0 
435fa000-435fb000 ---p 435fa000 00:00 0 
435fb000-439f4000 rwxp 435fb000 00:00 0 
439f4000-439f7000 ---p 439f4000 00:00 0 
439f7000-43af5000 rwxp 439f7000 00:00 0 
43af5000-43af8000 ---p 43af5000 00:00 0 
43af8000-43bf6000 rwxp 43af8000 00:00 0 
382b800000-382b81a000 r-xp 00000000 08:02 2312950                       
/lib64/ld-2.5.so
382ba1a000-382ba1b000 r--p 0001a000 08:02 2312950                       
/lib64/ld-2.5.so
382ba1b000-382ba1c000 rw-p 0001b000 08:02 2312950                       
/lib64/ld-2.5.so
382bc00000-382bd4a000 r-xp 00000000 08:02 2312952                       
/lib64/libc-2.5.so
382bd4a000-382bf4a000 ---p 0014a000 08:02 2312952                       
/lib64/libc-2.5.so
382bf4a000-382bf4e000 r--p 0014a000 08:02 2312952                       
/lib64/libc-2.5.so
382bf4e000-382bf4f000 rw-p 0014e000 08:02 2312952                       
/lib64/libc-2.5.so
382bf4f000-382bf54000 rw-p 382bf4f000 00:00 0 
382c000000-382c002000 r-xp 00000000 08:02 1661404                       
/lib64/libdl-2.5.so
382c002000-382c202000 ---p 00002000 08:02 1661404                       
/lib64/libdl-2.5.so
382c202000-382c203000 r--p 00002000 08:02 1661404                       
/lib64/libdl-2.5.so
382c203000-382c204000 rw-p 00003000 08:02 1661404                       
/lib64/libdl-2.5.so
382c400000-382c404000 r-xp 00000000 08:02 3528267                       
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so
382c404000-382c603000 ---p 00004000 08:02 3528267                       
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so
382c603000-382c604000 rw-p 00003000 08:02 3528267                       
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so
382c800000-382c815000 r-xp 00000000 08:02 1661429                       
/lib64/libpthread-2.5.so
382c815000-382ca14000 ---p 00015000 08:02 1661429                       
/lib64/libpthread-2.5.so
382ca14000-382ca15000 r--p 00014000 08:02 1661429                       
/lib64/libpthread-2.5.so
382ca15000-382ca16000 rw-p 00015000 08:02 1661429                       
/lib64/libpthread-2.5.so
382ca16000-382ca1a000 rw-p 382ca16000 00:00 0 
382cc00000-382cc14000 r-xp 00000000 08:02 1883612                       
/usr/lib64/libz.so.1.2.3
382cc14000-382ce13000 ---p 00014000 08:02 1883612                       
/usr/lib64/libz.so.1.2.3
382ce13000-382ce14000 rw-p 00013000 08:02 1883612                       
/usr/lib64/libz.so.1.2.3
3830400000-3830407000 r-xp 00000000 08:02 2312958                       
/lib64/librt-2.5.so
3830407000-3830607000 ---p 00007000 08:02 2312958                       
/lib64/librt-2.5.so
3830607000-3830608000 r--p 00007000 08:02 2312958                       
/lib64/librt-2.5.so
3830608000-3830609000 rw-p 00008000 08:02 2312958                       
/lib64/librt-2.5.so
3831c00000-3831c0d000 r-xp 00000000 08:02 1661403                       
/lib64/libgcc_s-4.1.2-20080102.so.1
3831c0d000-3831e0d000 ---p 0000d000 08:02 1661403                       
/lib64/libgcc_s-4.1.2-20080102.so.1
3831e0d000-3831e0e000 rw-p 0000d000 08:02 1661403                       
/lib64/libgcc_s-4.1.2-20080102.so.1
3835e00000-3835e15000 r-xp 00000000 08:02 2313092                       
/lib64/libnsl-2.5.so
3835e15000-3836014000 ---p 00015000 08:02 2313092                       
/lib64/libnsl-2.5.so
3836014000-3836015000 r--p 00014000 08:02 2313092                       
/lib64/libnsl-2.5.so
3836015000-3836016000 rw-p 00015000 08:02 2313092                       
/lib64/libnsl-2.5.so
3836016000-3836018000 rw-p 3836016000 00:00 0 
2aaaaaaab000-2aaaaaad3000 rw-p 2aaaaaaab000 00:00 0 
2aaaaaad5000-2aaaaaad6000 r--p 2aaaaaad5000 00:00 0 
2aaaaaad6000-2aaaaaad7000 rwxp 2aaaaaad6000 00:00 0 
2aaaaaad7000-2aaaaaadf000 r-xp 00000000 08:02 3521163                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libhpi.so
2aaaaaadf000-2aaaaacde000 ---p 00008000 08:02 3521163                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libhpi.so
2aaaaacde000-2aaaaacdf000 rw-p 00007000 08:02 3521163                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads/libhpi.so
2aaaaacdf000-2aaaaace0000 rw-p 2aaaaacdf000 00:00 0 
2aaaaace0000-2aaaaace8000 rw-s 00000000 00:14 22856                     
/tmp/hsperfdata_brucer/11407
2aaaaad07000-2aaaaad11000 r-xp 00000000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaad11000-2aaaaaf10000 ---p 0000a000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaaf10000-2aaaaaf11000 r--p 00009000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaaf11000-2aaaaaf12000 rw-p 0000a000 08:02 2312921                   
/lib64/libnss_files-2.5.so
2aaaaaf12000-2aaaaaf20000 r-xp 00000000 08:02 3521160                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libverify.so
2aaaaaf20000-2aaaab11f000 ---p 0000e000 08:02 3521160                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libverify.so
2aaaab11f000-2aaaab121000 rw-p 0000d000 08:02 3521160                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libverify.so
2aaaab121000-2aaaab14c000 r-xp 00000000 08:02 3521142                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
2aaaab14c000-2aaaab34c000 ---p 0002b000 08:02 3521142                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
2aaaab34c000-2aaaab350000 rw-p 0002b000 08:02 3521142                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
2aaaab350000-2aaaab357000 r-xp 00000000 08:02 3521161                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libzip.so
2aaaab357000-2aaaab556000 ---p 00007000 08:02 3521161                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libzip.so
2aaaab556000-2aaaab557000 rw-p 00006000 08:02 3521161                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libzip.so
2aaaab557000-2aaaab7c7000 rwxp 2aaaab557000 00:00 0 
2aaaab7c7000-2aaaae557000 rwxp 2aaaab7c7000 00:00 0 
2aaaae557000-2aaaae561000 rwxp 2aaaae557000 00:00 0 
2aaaae561000-2aaaae617000 rwxp 2aaaae561000 00:00 0 
2aaaae620000-2aaaafae0000 rwxp 2aaaae620000 00:00 0 
2aaaafae0000-2aaab3a20000 rwxp 2aaaafae0000 00:00 0 
2aaab3a20000-2aaade4d0000 rwxp 2aaab3a20000 00:00 0 
2aaade4d0000-2aab5e4d0000 rwxp 2aaade4d0000 00:00 0 
2aab5e4d0000-2aab73a20000 rwxp 2aab5e4d0000 00:00 0 
2aab73a20000-2aabb3a20000 rwxp 2aab73a20000 00:00 0 
2aabb3a20000-2aabb3a2b000 rwxp 2aabb3a20000 00:00 0 
2aabb3a2b000-2aabb3a4a000 rwxp 2aabb3a2b000 00:00 0 
2aabb3a4a000-2aabb3ba0000 rwxp 2aabb3a4a000 00:00 0 
2aabb3ba0000-2aabb3f9f000 rwxp 2aabb3ba0000 00:00 0 
2aabb3f9f000-2aabb404a000 rwxp 2aabb3f9f000 00:00 0 
2aabb404a000-2aabb424a000 rwxp 2aabb404a000 00:00 0 
2aabb424a000-2aabb43a1000 rwxp 2aabb424a000 00:00 0 
2aabb43a1000-2aabb47a1000 rwxp 2aabb43a1000 00:00 0 
2aabb47a1000-2aabb47ac000 rwxp 2aabb47a1000 00:00 0 
2aabb47ac000-2aabb47cb000 rwxp 2aabb47ac000 00:00 0 
2aabb47cb000-2aabb4969000 r--s 01803000 08:02 3521228                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/rt.jar
2aabb4969000-2aabb4ac7000 rw-p 2aabb4969000 00:00 0 
2aabb4ac7000-2aabb4ad0000 r--s 00060000 08:02 3521184                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/ext/gnome-java-bridge.jar
2aabb4ad0000-2aabb4ad2000 r--s 0000b000 08:05 68059640                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/mosek.jar
2aabb4ad2000-2aabb4ad5000 r--s 00039000 08:02 3521213                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/jsse.jar
2aabb4ad5000-2aabb4b25000 r-xp 00000000 08:05 68059648                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosekjava5_0.so
2aabb4b25000-2aabb4c25000 ---p 00050000 08:05 68059648                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosekjava5_0.so
2aabb4c25000-2aabb4c26000 rw-p 00050000 08:05 68059648                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosekjava5_0.so
2aabb4c26000-2aabb528c000 r-xp 00000000 08:05 68059641                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosek64.so.5.0
2aabb528c000-2aabb538b000 ---p 00666000 08:05 68059641                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosek64.so.5.0
2aabb538b000-2aabb53bd000 rw-p 00665000 08:05 68059641                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libmosek64.so.5.0
2aabb53bd000-2aabb53c0000 rw-p 2aabb53bd000 00:00 0 
2aabb53c0000-2aabb53fe000 r-xp 00000000 08:05 68059639                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libirc.so
2aabb53fe000-2aabb54fd000 ---p 0003e000 08:05 68059639                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libirc.so
2aabb54fd000-2aabb54ff000 rw-p 0003d000 08:05 68059639                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libirc.so
2aabb54ff000-2aabb5500000 rw-p 2aabb54ff000 00:00 0 
2aabb5500000-2aabb5765000 r-xp 00000000 08:05 68059657                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libimf.so
2aabb5765000-2aabb5864000 ---p 00265000 08:05 68059657                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libimf.so
2aabb5864000-2aabb5869000 rw-p 00264000 08:05 68059657                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libimf.so
2aabb5869000-2aabb58a9000 r-xp 00000000 08:05 68059643                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libguide.so
2aabb58a9000-2aabb59a8000 ---p 00040000 08:05 68059643                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libguide.so
2aabb59a8000-2aabb59ab000 rw-p 0003f000 08:05 68059643                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libguide.so
2aabb59ab000-2aabb59b1000 rw-p 2aabb59ab000 00:00 0 
2aabb59b1000-2aabb59d1000 r-xp 00000000 08:05 68059635                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libsvml.so
2aabb59d1000-2aabb5ad0000 ---p 00020000 08:05 68059635                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libsvml.so
2aabb5ad0000-2aabb5af4000 rw-p 0001f000 08:05 68059635                  
/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin/libsvml.so
2aabb8000000-2aabb8021000 rw-p 2aabb8000000 00:00 0 
2aabb8021000-2aabbc000000 ---p 2aabb8021000 00:00 0 
2ba5d7d82000-2ba5d7d84000 rw-p 2ba5d7d82000 00:00 0 
2ba5d7dab000-2ba5d7dae000 rw-p 2ba5d7dab000 00:00 0 
2ba5d7dae000-2ba5d84ea000 r-xp 00000000 08:02 3521167                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
2ba5d84ea000-2ba5d86ea000 ---p 0073c000 08:02 3521167                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
2ba5d86ea000-2ba5d8762000 rw-p 0073c000 08:02 3521167                   
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
2ba5d8762000-2ba5d879b000 rw-p 2ba5d8762000 00:00 0 
2ba5d87c2000-2ba5d8844000 r-xp 00000000 08:02 1661430                   
/lib64/libm-2.5.so
2ba5d8844000-2ba5d8a43000 ---p 00082000 08:02 1661430                   
/lib64/libm-2.5.so
2ba5d8a43000-2ba5d8a44000 r--p 00081000 08:02 1661430                   
/lib64/libm-2.5.so
2ba5d8a44000-2ba5d8a45000 rw-p 00082000 08:02 1661430                   
/lib64/libm-2.5.so
7fffd2d12000-7fffd2d25000 rwxp 7fffd2d12000 00:00 0                     
[stack]
7fffd2d25000-7fffd2d28000 rw-p 7fffd2d25000 00:00 0 
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]

VM Arguments:
jvm_args: -Xms1024m -Xmx4096m 
java_command: qcqo1.qcqo1
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk.x86_64
PATH=/data2/r-project/bin:/home/brucer/bin:/work/loc0/prod/bbin:/work/loc2/prod/bbin:/work/loc2/prod/pbin:/work/loc2/prod/pybin:/work/loc2/prod/bin:/work/loc1/prod/bin:/data1/bruce/gcc/bin:/data2/r-project/bin:/home/brucer/bin:/work/loc0/prod/bbin:/work/loc2/prod/bbin:/work/loc2/prod/pbin:/work/loc2/prod/pybin:/work/loc2/prod/bin:/work/loc1/prod/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/brucer/bin:/work/loc2/prod/bin/hcsv:/work/loc0/prod/mod/utils:/home/brucer/bin:/home/brucer/bin:/work/loc2/prod/bin/hcsv:/work/loc0/prod/mod/utils
USERNAME=brucer
LD_LIBRARY_PATH=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/data1/bruce/java/mosek/5/tools/platform/linux64x86/bin:/data1/bruce/lib:/data2/r-project/lib64/R/lib:/data2/r-project/bin:/work/loc1/lib64:/work/opt/lib/wombat408:/usr/lib/oracle/10.2.0.4/client64/lib
SHELL=/bin/bash
DISPLAY=:0.0

Signal Handlers:
SIGSEGV: [libjvm.so+0x618cc0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x618cc0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGXFSZ: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x4dceb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x4e0340], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x4de2e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004


---------------  S Y S T E M  ---------------

OS:Red Hat Enterprise Linux Server release 5.2 (Tikanga)

uname:Linux 2.6.18-92.1.22.el5 #1 SMP Fri Dec 5 09:28:22 EST 2008 x86_64
libc:glibc 2.5 NPTL 2.5 
rlimit: STACK 10240k, CORE infinity, NPROC 135168, NOFILE 1024, AS infinity
load average:0.39 0.48 0.36

CPU:total 8 (4 cores per cpu, 1 threads per core) family 6 model 7 stepping 6,
cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3

Memory: 4k page, physical 16312852k(6475052k free), swap 8546540k(1728304k
free)

vm_info: OpenJDK 64-Bit Server VM (1.6.0_0-b11) for linux-amd64 JRE
(1.6.0_0-b11), built on Jul 25 2008 06:43:15 by "mockbuild" with gcc 4.1.2
20071124 (Red Hat 4.1.2-42)

time: Tue Jan  6 15:02:58 2009
elapsed time: 4 seconds


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 06:08:14 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 14:08:14 +0000
Subject: [Bug 276] SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKZ4w-0001kV-0A@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=276





------- Comment #2 from bruce.roscherr at citi.com  2009-01-07 14:08 -------
I was hoping someone would say "well dummy, you didn't do XXXX". I understand
the need for an example, but I have no experience with writing C code with
ptherads. I could describe how to do it with Intel's MKL that is freely
downloadable, but I'm not in a position to produce a self contained example
right now.

I have learned that both the vendors whos software is producing this error for
me, use Intel's libguide threading library. They are not independent code bases
as I had thought, which would make libguide the most likely culprit.

I have discovered that setting -XX:ReservedCodeCacheSize to some high number,
makes the crash go away. This is not a good solution as the required value for
this setting is very problem dependent (larger problems sometimes need smaller
values set), but I am trying to get Intel to look into the problem.

Thanks
-Bruce


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 06:13:30 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 14:13:30 +0000
Subject: [Bug 278] SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKZA2-0001lB-FB@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=278


aph at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




------- Comment #1 from aph at redhat.com  2009-01-07 14:13 -------


*** This bug has been marked as a duplicate of bug 276 ***


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 06:13:30 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 14:13:30 +0000
Subject: [Bug 276] SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKZA2-0001lF-Kl@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=276





------- Comment #3 from aph at redhat.com  2009-01-07 14:13 -------
*** Bug 278 has been marked as a duplicate of this bug. ***


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 06:13:30 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 14:13:30 +0000
Subject: [Bug 279] SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKZA2-0001lN-Tn@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=279


Bug 279 depends on bug 278, which changed state.

Bug 278 Summary: SIGSEGV in 64 bit JDK 1.6 when using JNI, and both library and Java app are threaded
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=278

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE



-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 06:13:59 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 14:13:59 +0000
Subject: [Bug 279] SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKZAV-0001lY-NS@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=279


aph at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




------- Comment #1 from aph at redhat.com  2009-01-07 14:13 -------


*** This bug has been marked as a duplicate of bug 276 ***


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Wed Jan  7 06:13:59 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 07 Jan 2009 14:13:59 +0000
Subject: [Bug 276] SIGSEGV in 64 bit JDK 1.6 when using JNI,
	and both library and Java app are threaded
Message-ID: <E1LKZAV-0001ld-Sc@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=276





------- Comment #4 from aph at redhat.com  2009-01-07 14:13 -------
*** Bug 279 has been marked as a duplicate of this bug. ***


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From theBohemian at gmx.net  Wed Jan  7 14:05:16 2009
From: theBohemian at gmx.net (Robert Schuster)
Date: Wed, 07 Jan 2009 23:05:16 +0100
Subject: Patch: allow specifiying flags to the VM used in javac script
Message-ID: <4965271C.8010003@gmx.net>

Hi,
you may laugh but this is the most simple patch to make cross-compiling
OpenJDK easier. The reason is that I run ecj with jamvm/cacao which have
a far to small default maximum heap size to comple hotspot-tools.

With this patch I can ' JAVA_FLAGS="-Xmx4096M" configure ' and
everything is fine. :)

2009-01-07  Robert Schuster <robertschuster at fsfe.org>

  * javac.in: Added variable @JAVA_FLAGS@ .
  * configure.ac: Added AC_SUBST for JAVA_FLAGS.

Regards
Robert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090107/0d2c2efa/attachment.bin 

From martinrb at google.com  Wed Jan  7 14:43:03 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 7 Jan 2009 14:43:03 -0800
Subject: Patch: allow specifiying flags to the VM used in javac script
In-Reply-To: <4965271C.8010003@gmx.net>
References: <4965271C.8010003@gmx.net>
Message-ID: <1ccfd1c10901071443h13c1a35ft576273ee1c06e89d@mail.gmail.com>

Why not use the -J flag?

$ javac -help
....
  -J<flag>                   Pass <flag> directly to the runtime system

Martin

On Wed, Jan 7, 2009 at 14:05, Robert Schuster <theBohemian at gmx.net> wrote:
> Hi,
> you may laugh but this is the most simple patch to make cross-compiling
> OpenJDK easier. The reason is that I run ecj with jamvm/cacao which have
> a far to small default maximum heap size to comple hotspot-tools.
>
> With this patch I can ' JAVA_FLAGS="-Xmx4096M" configure ' and
> everything is fine. :)
>
> 2009-01-07  Robert Schuster <robertschuster at fsfe.org>
>
>  * javac.in: Added variable @JAVA_FLAGS@ .
>  * configure.ac: Added AC_SUBST for JAVA_FLAGS.
>
> Regards
> Robert
>
>


From ekrichardson at gmail.com  Wed Jan  7 20:56:25 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Wed, 7 Jan 2009 20:56:25 -0800
Subject: Problem Compiling Java
Message-ID: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>

Hello,

Before I burn too many cycles trying to figure out what is going on I
thought I'd see if anyone has any ideas. I'm working with icetea6 on Power
PC Mac OS X. I know that the BSD stuff is in Icedtea7 but since I am trying
to compile with the Apple jdk5 java and am waiting for icedtea7 to remove
the --with-libgcj-jar as I can't get past the ./configure step with icetea7.
Since this is removed in icedtea6 I can get past ./configure but it ignores
the --with-project=bsd. I figure, perhaps wrongly that I should be able to
compile Java at least. The VirtualMachineImpl.java has an import of
ClassTypeImpl in the same package which in turn imports com.sun.jdi,* which
has ClassType but the incorrect classpath error mentions a ClassType in a
different package. I changed the Makefile to get more memory.

Eric

patrizia-imac-g5:icedtea6 eric$ make
if ! test -d /Users/eric/java/icedtea6/bootstrap/jdk1.6.0 ; \
    then \
      /opt/local/bin/ecj -nowarn -J-Xmx4096m -g -d lib/hotspot-tools \
            -source 1.5 \
            -sourcepath \

'hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/Users/eric/java/icedtea6/generated:/Users/eric/java/icedtea6/rt'
\
            -bootclasspath '' @hotspot-tools-source-files.txt ; \
    else \
      /Users/eric/java/icedtea6/bootstrap/jdk1.6.0/bin/javac -J-Xmx4096m -g
\
        -d lib/hotspot-tools \
        -source 1.5 \
        -sourcepath \

'hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/Users/eric/java/icedtea6/generated:/Users/eric/java/icedtea6/rt'
\
        -bootclasspath '' @hotspot-tools-source-files.txt ; \
    fi
incorrect classpath: hotspot-tools/com/sun/codemodel/internal/ClassType.java
----------
1. ERROR in
/Users/eric/java/icedtea6/openjdk/jdk/src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java
(at line 0)
    /*
    ^
Internal compiler error
java.lang.OutOfMemoryError: Java heap space
    at
org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsCharArray(Unknown
Source)
    at
org.eclipse.jdt.internal.compiler.util.Util.getFileCharContent(Unknown
Source)
    at
org.eclipse.jdt.internal.compiler.batch.CompilationUnit.getContents(Unknown
Source)
    at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Unknown Source)
    at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Unknown Source)
    at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Unknown
Source)
    at org.eclipse.jdt.internal.compiler.Compiler.accept(Unknown Source)
    at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(Unknown
Source)
    at
org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(Unknown
Source)
    at
org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Unknown
Source)
    at org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Unknown
Source)
    at
org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(Unknown
Source)
    at
org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(Unknown
Source)
    at
org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypeFor(Unknown
Source)
    at
org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.fields(Unknown
Source)
    at
org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.faultInTypesForFieldsAndMethods(Unknown
Source)
    at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(Unknown
Source)
    at org.eclipse.jdt.internal.compiler.Compiler.process(Unknown Source)
    at org.eclipse.jdt.internal.compiler.Compiler.compile(Unknown Source)
    at
org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Unknown
Source)
    at org.eclipse.jdt.internal.compiler.batch.Main.compile(Unknown Source)
    at org.eclipse.jdt.internal.compiler.batch.Main.main(Unknown Source)

----------
1 problem (1 error)make: *** [stamps/hotspot-tools-class-files.stamp] Error
255
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090107/c6f51af8/attachment.html 

From christian.thalinger at gmail.com  Thu Jan  8 01:22:31 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Thu, 08 Jan 2009 10:22:31 +0100
Subject: Problem Compiling Java
In-Reply-To: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
Message-ID: <1231406551.16494.32.camel@localhost.localdomain>

On Wed, 2009-01-07 at 20:56 -0800, Eric Richardson wrote:
> I changed the Makefile to get more memory.

> patrizia-imac-g5:icedtea6 eric$ make
> if ! test -d /Users/eric/java/icedtea6/bootstrap/jdk1.6.0 ; \
>     then \
>       /opt/local/bin/ecj -nowarn -J-Xmx4096m -g -d lib/hotspot-tools \
>             -source 1.5 \
>             -sourcepath \
> 
> 'hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/Users/eric/java/icedtea6/generated:/Users/eric/java/icedtea6/rt' \
>             -bootclasspath '' @hotspot-tools-source-files.txt ; \
>     else \
>       /Users/eric/java/icedtea6/bootstrap/jdk1.6.0/bin/javac
> -J-Xmx4096m -g \

Is bootstrap/jdk1.6.0/bin/javac using ECJ or Apple's Javac?  If it's
ECJ, -J options are ignored.

- Christian



From christian.thalinger at gmail.com  Thu Jan  8 01:29:13 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Thu, 08 Jan 2009 10:29:13 +0100
Subject: Patch: allow specifiying flags to the VM used in javac script
In-Reply-To: <1ccfd1c10901071443h13c1a35ft576273ee1c06e89d@mail.gmail.com>
References: <4965271C.8010003@gmx.net>
	<1ccfd1c10901071443h13c1a35ft576273ee1c06e89d@mail.gmail.com>
Message-ID: <1231406953.16494.35.camel@localhost.localdomain>

On Wed, 2009-01-07 at 14:43 -0800, Martin Buchholz wrote:
> Why not use the -J flag?
> 
> $ javac -help
> ....
>   -J<flag>                   Pass <flag> directly to the runtime system

As I wrote in another email two minutes ago:

$ ecj -help
<snip>
 Ignored options:
    -J<option>         pass option to virtual machine (ignored)

- Christian



From mvfranz at gmail.com  Thu Jan  8 04:14:55 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Thu, 8 Jan 2009 07:14:55 -0500
Subject: Problem Compiling Java
In-Reply-To: <1231406551.16494.32.camel@localhost.localdomain>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
Message-ID: <fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>

Eric,

You can edit your /opt/local/bin/ecj scrip to have a larger memory setting.
I use -Xmx768m.

java -Xmx768M org.eclipse.jdt.internal.compiler.batch.Main "$@"

I cannot not explain all the details, but since ecj is a shell script it
does not handle passing parameters all that well to java.  I have found
other people's attempts and I have tried my self.  There is all kinds of fun
trying to deal with the shell expanding parameters when they need to be
passed verbatim.

Michael
On Thu, Jan 8, 2009 at 4:22 AM, Christian Thalinger <
christian.thalinger at gmail.com> wrote:

> On Wed, 2009-01-07 at 20:56 -0800, Eric Richardson wrote:
> > I changed the Makefile to get more memory.
>
> > patrizia-imac-g5:icedtea6 eric$ make
> > if ! test -d /Users/eric/java/icedtea6/bootstrap/jdk1.6.0 ; \
> >     then \
> >       /opt/local/bin/ecj -nowarn -J-Xmx4096m -g -d lib/hotspot-tools \
> >             -source 1.5 \
> >             -sourcepath \
> >
> >
> 'hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/Users/eric/java/icedtea6/generated:/Users/eric/java/icedtea6/rt'
> \
> >             -bootclasspath '' @hotspot-tools-source-files.txt ; \
> >     else \
> >       /Users/eric/java/icedtea6/bootstrap/jdk1.6.0/bin/javac
> > -J-Xmx4096m -g \
>
> Is bootstrap/jdk1.6.0/bin/javac using ECJ or Apple's Javac?  If it's
> ECJ, -J options are ignored.
>
> - Christian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090108/e077a221/attachment.html 

From gnu_andrew at member.fsf.org  Thu Jan  8 04:45:52 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 8 Jan 2009 12:45:52 +0000
Subject: Problem Compiling Java
In-Reply-To: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
Message-ID: <17c6771e0901080445r7eee1530u7d9aa54ffca4ad3c@mail.gmail.com>

2009/1/8 Eric Richardson <ekrichardson at gmail.com>:
> Hello,
>

>I know that the BSD stuff is in Icedtea7 but since I am trying
>to compile with the Apple jdk5 java and am waiting for icedtea7 to remove
>the --with-libgcj-jar as I can't get past the ./configure step with icetea7.
>Since this is removed in icedtea6 I can get past ./configure but it ignores
>the --with-project=bsd.

You won't get very far without BSD support I presume.  We should look
at supporting the necessary BSD changes in IcedTea directly as a
separate 7 tree is impractical for any real use.

You shouldn't need the libgcj-jar support removing.  Just specify the
extra option, pointing to your rt.jar.
-- 
Andrew :-)

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


From theBohemian at gmx.net  Thu Jan  8 05:41:33 2009
From: theBohemian at gmx.net (Robert Schuster)
Date: Thu, 08 Jan 2009 14:41:33 +0100
Subject: Patch: allow specifiying flags to the VM used in javac script
In-Reply-To: <4965271C.8010003@gmx.net>
References: <4965271C.8010003@gmx.net>
Message-ID: <4966028D.70303@gmx.net>

Hi,
great stuff I forgot the actual patch. :)

@Twisti/Martin: The patch only affects the 'javac' script in IcedTea's
toplevel directory. This script calls ecj directly IOW without calling
another ecj program/script.

Regards
Robert

Robert Schuster schrieb:
> Hi,
> you may laugh but this is the most simple patch to make cross-compiling
> OpenJDK easier. The reason is that I run ecj with jamvm/cacao which have
> a far to small default maximum heap size to comple hotspot-tools.
> 
> With this patch I can ' JAVA_FLAGS="-Xmx4096M" configure ' and
> everything is fine. :)
> 
> 2009-01-07  Robert Schuster <robertschuster at fsfe.org>
> 
>   * javac.in: Added variable @JAVA_FLAGS@ .
>   * configure.ac: Added AC_SUBST for JAVA_FLAGS.
> 
> Regards
> Robert
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: java_flags.patch
Type: text/x-patch
Size: 679 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090108/b6bdbc49/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090108/b6bdbc49/attachment-0001.bin 

From mark at klomp.org  Thu Jan  8 06:05:53 2009
From: mark at klomp.org (Mark Wielaard)
Date: Thu, 08 Jan 2009 15:05:53 +0100
Subject: Patch: allow specifiying flags to the VM used in javac script
In-Reply-To: <4966028D.70303@gmx.net>
References: <4965271C.8010003@gmx.net>  <4966028D.70303@gmx.net>
Message-ID: <1231423553.3444.27.camel@dijkstra.wildebeest.org>

Hi Robert,

On Thu, 2009-01-08 at 14:41 +0100, Robert Schuster wrote:
> Robert Schuster schrieb:
> > you may laugh but this is the most simple patch to make cross-compiling
> > OpenJDK easier. The reason is that I run ecj with jamvm/cacao which have
> > a far to small default maximum heap size to comple hotspot-tools.
> > 
> > With this patch I can ' JAVA_FLAGS="-Xmx4096M" configure ' and
> > everything is fine. :)
> > 
> > 2009-01-07  Robert Schuster <robertschuster at fsfe.org>
> > 
> >   * javac.in: Added variable @JAVA_FLAGS@ .
> >   * configure.ac: Added AC_SUBST for JAVA_FLAGS.

Wouldn't it be better to make sure there is always enough memory for the
compiler? I think just adding -Xmx4096M directly to javac.in might be
easier than have people try, fail because their java has a too low
default and having to reconfigure. Or do you need something this for
other stuff also?

Martin does have a point, it would be good if the javac.in script did
understand -J. That is kind of why we have javac.in as wrapper, so you
can translate unknown options to something know for the detected
compiler. Then you could push the exact memory needed up into the actual
javac invocation. Assuming that there are not too many places that need
to expand the default memory settings of course. Otherwise setting it
default to something large enough for everything seems better.

Cheers,

Mark



From ekrichardson at gmail.com  Thu Jan  8 09:06:01 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Thu, 8 Jan 2009 09:06:01 -0800
Subject: Problem Compiling Java
In-Reply-To: <1231406551.16494.32.camel@localhost.localdomain>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
Message-ID: <860cb0120901080906k22b98330l552550eb351577ce@mail.gmail.com>

Christian,

On Thu, Jan 8, 2009 at 1:22 AM, Christian Thalinger <
christian.thalinger at gmail.com> wrote:

> On Wed, 2009-01-07 at 20:56 -0800, Eric Richardson wrote:
> > I changed the Makefile to get more memory.
>
> > patrizia-imac-g5:icedtea6 eric$ make
> > if ! test -d /Users/eric/java/icedtea6/bootstrap/jdk1.6.0 ; \
> >     then \
> >       /opt/local/bin/ecj -nowarn -J-Xmx4096m -g -d lib/hotspot-tools \
> >             -source 1.5 \
> >             -sourcepath \
> >
> >
> 'hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/Users/eric/java/icedtea6/generated:/Users/eric/java/icedtea6/rt'
> \
> >             -bootclasspath '' @hotspot-tools-source-files.txt ; \
> >     else \
> >       /Users/eric/java/icedtea6/bootstrap/jdk1.6.0/bin/javac
> > -J-Xmx4096m -g \
>
> Is bootstrap/jdk1.6.0/bin/javac using ECJ or Apple's Javac?  If it's
> ECJ, -J options are ignored.


Yes, it is taking the ecj path. It seemed that configure would not let me
cointinue without installing ecj though. But I am very new to this and am
learning how this all works.


> - Christian
>

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090108/eb6d4ba5/attachment.html 

From ekrichardson at gmail.com  Thu Jan  8 09:11:21 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Thu, 8 Jan 2009 09:11:21 -0800
Subject: Problem Compiling Java
In-Reply-To: <fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
Message-ID: <860cb0120901080911n9433d8fjf5b3b5f06bf373cf@mail.gmail.com>

Michael,

On Thu, Jan 8, 2009 at 4:14 AM, Michael Franz <mvfranz at gmail.com> wrote:

> Eric,
>
> You can edit your /opt/local/bin/ecj scrip to have a larger memory
> setting.  I use -Xmx768m.
>
> java -Xmx768M org.eclipse.jdt.internal.compiler.batch.Main "$@"
>
> I cannot not explain all the details, but since ecj is a shell script it
> does not handle passing parameters all that well to java.  I have found
> other people's attempts and I have tried my self.  There is all kinds of fun
> trying to deal with the shell expanding parameters when they need to be
> passed verbatim.


Sure, I can definitely try this edit. I remember how obscure shell scripts
can be in this regard.

Eric


>
>
> Michael
>
> On Thu, Jan 8, 2009 at 4:22 AM, Christian Thalinger <
> christian.thalinger at gmail.com> wrote:
>
>> On Wed, 2009-01-07 at 20:56 -0800, Eric Richardson wrote:
>> > I changed the Makefile to get more memory.
>>
>> > patrizia-imac-g5:icedtea6 eric$ make
>> > if ! test -d /Users/eric/java/icedtea6/bootstrap/jdk1.6.0 ; \
>> >     then \
>> >       /opt/local/bin/ecj -nowarn -J-Xmx4096m -g -d lib/hotspot-tools \
>> >             -source 1.5 \
>> >             -sourcepath \
>> >
>> >
>> 'hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/Users/eric/java/icedtea6/generated:/Users/eric/java/icedtea6/rt'
>> \
>> >             -bootclasspath '' @hotspot-tools-source-files.txt ; \
>> >     else \
>> >       /Users/eric/java/icedtea6/bootstrap/jdk1.6.0/bin/javac
>> > -J-Xmx4096m -g \
>>
>> Is bootstrap/jdk1.6.0/bin/javac using ECJ or Apple's Javac?  If it's
>> ECJ, -J options are ignored.
>>
>> - Christian
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090108/74053dda/attachment.html 

From ekrichardson at gmail.com  Thu Jan  8 09:17:20 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Thu, 8 Jan 2009 09:17:20 -0800
Subject: Problem Compiling Java
In-Reply-To: <17c6771e0901080445r7eee1530u7d9aa54ffca4ad3c@mail.gmail.com>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<17c6771e0901080445r7eee1530u7d9aa54ffca4ad3c@mail.gmail.com>
Message-ID: <860cb0120901080917v7429750ah3fb93aee3a517b2d@mail.gmail.com>

Andrew,

On Thu, Jan 8, 2009 at 4:45 AM, Andrew John Hughes <
gnu_andrew at member.fsf.org> wrote:

> 2009/1/8 Eric Richardson <ekrichardson at gmail.com>:
> > Hello,
> >
>
> >I know that the BSD stuff is in Icedtea7 but since I am trying
> >to compile with the Apple jdk5 java and am waiting for icedtea7 to remove
> >the --with-libgcj-jar as I can't get past the ./configure step with
> icetea7.
> >Since this is removed in icedtea6 I can get past ./configure but it
> ignores
> >the --with-project=bsd.
>
> You won't get very far without BSD support I presume.  We should look
> at supporting the necessary BSD changes in IcedTea directly as a
> separate 7 tree is impractical for any real use.
>
> You shouldn't need the libgcj-jar support removing.  Just specify the
> extra option, pointing to your rt.jar.


I guess I misunderstood your post about the JRE structure. I was pointing to
the rt.jar previously but thought this was wrong. I did create the JRE
structure so if the changes you made in icedtea6 rely on the standard layout
then it works.  I will try the icetea7 again with these suggestions.

Eric


> --
> Andrew :-)
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090108/fde31f36/attachment.html 

From christian.thalinger at gmail.com  Thu Jan  8 11:45:45 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Thu, 08 Jan 2009 19:45:45 +0000
Subject: changeset in /hg/icedtea6: 2009-01-08  Christian Thalinger  <chr...
Message-ID: <hg.2938e5bb0575.1231443944.2873452341184383832@icedtea.classpath.org>

changeset 2938e5bb0575 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=2938e5bb0575
description:
	2009-01-08  Christian Thalinger  <christian.thalinger at gmail.com>

		* acinclude.m4 (SET_OS_DIRS): New function.
		* configure.ac: Call SET_OS_DIRS and made ALSA check conditional.
		* Makefile.am (LINUX_DIR): Renamed to OS_DIR and use BUILD_OS_DIR
		variable.
		(ICEDTEA_ENV, ICEDTEA_ENV_ECJ): Added OS_PATH to PATH.

diffstat:

4 files changed, 44 insertions(+), 12 deletions(-)
ChangeLog    |    8 ++++++++
Makefile.am  |   10 +++++-----
acinclude.m4 |   19 +++++++++++++++++++
configure.ac |   19 ++++++++++++-------

diffs (116 lines):

diff -r f8d68d85e72e -r 2938e5bb0575 ChangeLog
--- a/ChangeLog	Wed Jan 07 12:02:05 2009 +0100
+++ b/ChangeLog	Thu Jan 08 20:45:32 2009 +0100
@@ -1,3 +1,11 @@ 2009-01-07  Matthias Klose  <doko at ubuntu
+2009-01-08  Christian Thalinger  <christian.thalinger at gmail.com>
+
+	* acinclude.m4 (SET_OS_DIRS): New function.
+	* configure.ac: Call SET_OS_DIRS and made ALSA check conditional.
+	* Makefile.am (LINUX_DIR): Renamed to OS_DIR and use BUILD_OS_DIR
+	variable.
+	(ICEDTEA_ENV, ICEDTEA_ENV_ECJ): Added OS_PATH to PATH.
+
 2009-01-07  Matthias Klose  <doko at ubuntu.com>
 
 	* patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch: New, fix
diff -r f8d68d85e72e -r 2938e5bb0575 Makefile.am
--- a/Makefile.am	Wed Jan 07 12:02:05 2009 +0100
+++ b/Makefile.am	Thu Jan 08 20:45:32 2009 +0100
@@ -112,9 +112,9 @@ EXTRA_DIST = rt generated \
 # name is completely irrelevant; only contains the plugs to build IcedTea.
 
 # OpenJDK build environment.
-LINUX_DIR = linux-$(BUILD_ARCH_DIR)
-BUILD_OUTPUT_DIR = openjdk/control/build/$(LINUX_DIR)
-ECJ_BUILD_OUTPUT_DIR = openjdk-ecj/control/build/$(LINUX_DIR)
+OS_DIR = $(BUILD_OS_DIR)-$(BUILD_ARCH_DIR)
+BUILD_OUTPUT_DIR = openjdk/control/build/$(OS_DIR)
+ECJ_BUILD_OUTPUT_DIR = openjdk-ecj/control/build/$(OS_DIR)
 ICEDTEA_BUILD_DIR = \
 	$(abs_top_builddir)/$(BUILD_OUTPUT_DIR)
 ICEDTEA_RT = \
@@ -150,7 +150,7 @@ ICEDTEA_ENV = \
         "JRE_RELEASE_VERSION=1.6.0_$(COMBINED_VERSION)" \
 	"MILESTONE=fcs" \
 	"LANG=C" \
-	"PATH=$(abs_top_builddir)/bootstrap/jdk1.6.0/bin:$$PATH" \
+	"PATH=$(abs_top_builddir)/bootstrap/jdk1.6.0/bin:$(OS_PATH):$$PATH" \
 	"ALT_BOOTDIR=$(ICEDTEA_BOOT_DIR)" \
 	"ALT_BINARY_PLUGS_PATH=$(abs_top_builddir)/bootstrap/jdk1.7.0" \
 	"BUILD_ARCH_DIR=$(BUILD_ARCH_DIR)" \
@@ -220,7 +220,7 @@ ICEDTEA_ENV_ECJ = \
         "JRE_RELEASE_VERSION=1.6.0_$(COMBINED_VERSION)" \
 	"MILESTONE=fcs" \
 	"LANG=C" \
-	"PATH=$(abs_top_builddir)/bootstrap/jdk1.6.0/bin:$$PATH" \
+	"PATH=$(abs_top_builddir)/bootstrap/jdk1.6.0/bin:$(OS_PATH):$$PATH" \
 	"ALT_BOOTDIR=$(ICEDTEA_BOOT_DIR)" \
 	"ALT_BINARY_PLUGS_PATH=$(abs_top_builddir)/bootstrap/jdk1.7.0" \
 	"BUILD_ARCH_DIR=$(BUILD_ARCH_DIR)" \
diff -r f8d68d85e72e -r 2938e5bb0575 acinclude.m4
--- a/acinclude.m4	Wed Jan 07 12:02:05 2009 +0100
+++ b/acinclude.m4	Thu Jan 08 20:45:32 2009 +0100
@@ -66,6 +66,25 @@ AC_DEFUN([SET_ARCH_DIRS],
   AC_SUBST(ARCH_PREFIX)
 ])
 
+AC_DEFUN([SET_OS_DIRS],
+[
+  case "${host_os}" in
+    *linux*)
+      BUILD_OS_DIR=linux
+      OS_PATH=
+      ;;
+    *solaris*)
+      BUILD_OS_DIR=solaris
+      OS_PATH=/opt/SunStudioExpress/bin:/opt/SUNWpro/bin:/usr/gnu/bin
+      ;;
+    *)
+      AC_MSG_ERROR([unsupported operating system ${host_os}])
+      ;;
+  esac
+  AC_SUBST(BUILD_OS_DIR)
+  AC_SUBST(OS_PATH)
+])
+
 AC_DEFUN([FIND_JAVAC],
 [
   user_specified_javac=
diff -r f8d68d85e72e -r 2938e5bb0575 configure.ac
--- a/configure.ac	Wed Jan 07 12:02:05 2009 +0100
+++ b/configure.ac	Thu Jan 08 20:45:32 2009 +0100
@@ -203,6 +203,8 @@ AC_SUBST(DIST_ID)
 AC_SUBST(DIST_ID)
 
 SET_ARCH_DIRS
+SET_OS_DIRS
+
 if test "${with_openjdk}" = true
 then
   AC_CHECK_FOR_OPENJDK
@@ -374,15 +376,18 @@ AC_SUBST(FREETYPE2_CFLAGS)
 AC_SUBST(FREETYPE2_CFLAGS)
 AC_SUBST(FREETYPE2_LIBS)
 
-dnl Check for alsa headers and libraries.
-PKG_CHECK_MODULES(ALSA, alsa,[ALSA_FOUND=yes],[ALSA_FOUND=no])
-if test "x${ALSA_FOUND}" = xno
-then
-  AC_MSG_ERROR([Could not find alsa - \
-  Try installing alsa-lib-devel.])
-fi
+dnl Check for alsa headers and libraries (only required for Linux).
+if test "x${BUILD_OS_DIR}" = "xlinux"
+then
+  PKG_CHECK_MODULES(ALSA, alsa,[ALSA_FOUND=yes],[ALSA_FOUND=no])
+  if test "x${ALSA_FOUND}" = xno
+  then
+    AC_MSG_ERROR([Could not find alsa - \
+    Try installing alsa-lib-devel.])
+  fi
 AC_SUBST(ALSA_CFLAGS)
 AC_SUBST(ALSA_LIBS)
+fi
 
 if test "x${enable_pulse_java}" = "xyes"
 then


From doko at ubuntu.com  Thu Jan  8 13:16:49 2009
From: doko at ubuntu.com (doko at ubuntu.com)
Date: Thu, 08 Jan 2009 21:16:49 +0000
Subject: changeset in /hg/icedtea6: 2009-01-08  Matthias Klose  <doko@ubu...
Message-ID: <hg.48a808c06395.1231449409.2873452341184383832@icedtea.classpath.org>

changeset 48a808c06395 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=48a808c06395
description:
	2009-01-08  Matthias Klose  <doko at ubuntu.com>

	        * patches/hotspot/14.0b08/icedtea-no-precompiled.patch: Don't use
	        precompiled header files in hotspot.
	        * HACKING: Document the above.

diffstat:

3 files changed, 39 insertions(+)
ChangeLog                                            |    6 +++
HACKING                                              |    1 
patches/hotspot/14.0b08/icedtea-no-precompiled.patch |   32 ++++++++++++++++++

diffs (60 lines):

diff -r 2938e5bb0575 -r 48a808c06395 ChangeLog
--- a/ChangeLog	Thu Jan 08 20:45:32 2009 +0100
+++ b/ChangeLog	Thu Jan 08 22:15:08 2009 +0100
@@ -1,3 +1,9 @@ 2009-01-08  Christian Thalinger  <christ
+2009-01-08  Matthias Klose  <doko at ubuntu.com>
+
+	* patches/hotspot/14.0b08/icedtea-no-precompiled.patch: Don't use
+	precompiled header files in hotspot.
+	* HACKING: Document the above.
+
 2009-01-08  Christian Thalinger  <christian.thalinger at gmail.com>
 
 	* acinclude.m4 (SET_OS_DIRS): New function.
diff -r 2938e5bb0575 -r 48a808c06395 HACKING
--- a/HACKING	Thu Jan 08 20:45:32 2009 +0100
+++ b/HACKING	Thu Jan 08 22:15:08 2009 +0100
@@ -81,6 +81,7 @@ The following patches are currently appl
 * icedtea-a11y-property-change.patch: Dont fire PropertyChangeEvent if the property hasnt changed.
 * icedtea-demo-swingapplet.patch: Add missing html file needed to run the demo.
 * icedtea-hotspot-dispatch.patch: Fix build failure with GCC-4.4 (PR 38725).
+* icedtea-no-precompiled.patch: Don't use precompiled header files in hotspot.
 
 The following patches are only applied to OpenJDK6 in IcedTea6:
 
diff -r 2938e5bb0575 -r 48a808c06395 patches/hotspot/14.0b08/icedtea-no-precompiled.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/hotspot/14.0b08/icedtea-no-precompiled.patch	Thu Jan 08 22:15:08 2009 +0100
@@ -0,0 +1,32 @@
+--- openjdk/hotspot/make/linux/makefiles/gcc.make.orig	2009-01-04 13:51:38.000000000 +0000
++++ openjdk/hotspot/make/linux/makefiles/gcc.make	2009-01-04 13:53:34.000000000 +0000
+@@ -34,13 +34,6 @@
+ CC_VER_MAJOR := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.' -f1)
+ CC_VER_MINOR := $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.' -f2)
+ 
+-# check for precompiled headers support
+-ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 3 \) \| \( \( $(CC_VER_MAJOR) = 3 \) \& \( $(CC_VER_MINOR) \>= 4 \) \))" "0"
+-USE_PRECOMPILED_HEADER=1
+-PRECOMPILED_HEADER_DIR=.
+-PRECOMPILED_HEADER=$(PRECOMPILED_HEADER_DIR)/incls/_precompiled.incl.gch
+-endif
+-
+ 
+ #------------------------------------------------------------------------
+ # Compiler flags
+--- openjdk/hotspot/make/solaris/makefiles/gcc.make.orig	2009-01-04 14:44:12.000000000 +0000
++++ openjdk/hotspot/make/solaris/makefiles/gcc.make	2009-01-04 17:06:50.000000000 +0000
+@@ -45,13 +45,6 @@
+ $(shell $(CC) -dumpversion | sed 's/egcs-//' | cut -d'.' -f2)
+ 
+ 
+-# check for precompiled headers support
+-ifneq "$(shell expr \( $(CC_VER_MAJOR) \> 3 \) \| \( \( $(CC_VER_MAJOR) = 3 \) \& \( $(CC_VER_MINOR) \>= 4 \) \))" "0"
+-USE_PRECOMPILED_HEADER=1
+-PRECOMPILED_HEADER_DIR=.
+-PRECOMPILED_HEADER=$(PRECOMPILED_HEADER_DIR)/incls/_precompiled.incl.gch
+-endif
+-
+ 
+ #------------------------------------------------------------------------
+ # Compiler flags


From doko at ubuntu.com  Thu Jan  8 14:27:18 2009
From: doko at ubuntu.com (doko at ubuntu.com)
Date: Thu, 08 Jan 2009 22:27:18 +0000
Subject: changeset in /hg/icedtea6: 2009-01-08  Matthias Klose  <doko@ubu...
Message-ID: <hg.6c79e6c68d05.1231453638.2873452341184383832@icedtea.classpath.org>

changeset 6c79e6c68d05 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=6c79e6c68d05
description:
	2009-01-08  Matthias Klose  <doko at ubuntu.com>

	        PR icedtea/277
	        * patches/hotspot/14.0b08/icedtea-includedb.patch: New.
	        * Makefile.am: Apply.
	        * HACKING: Document the above.

diffstat:

4 files changed, 20 insertions(+), 1 deletion(-)
ChangeLog                                       |    7 +++++++
HACKING                                         |    1 +
Makefile.am                                     |    3 ++-
patches/hotspot/14.0b08/icedtea-includedb.patch |   10 ++++++++++

diffs (52 lines):

diff -r 48a808c06395 -r 6c79e6c68d05 ChangeLog
--- a/ChangeLog	Thu Jan 08 22:15:08 2009 +0100
+++ b/ChangeLog	Thu Jan 08 23:25:38 2009 +0100
@@ -1,3 +1,10 @@ 2009-01-08  Matthias Klose  <doko at ubuntu
+2009-01-08  Matthias Klose  <doko at ubuntu.com>
+
+	PR icedtea/277
+	* patches/hotspot/14.0b08/icedtea-includedb.patch: New.
+	* Makefile.am: Apply.
+	* HACKING: Document the above.
+
 2009-01-08  Matthias Klose  <doko at ubuntu.com>
 
 	* patches/hotspot/14.0b08/icedtea-no-precompiled.patch: Don't use
diff -r 48a808c06395 -r 6c79e6c68d05 HACKING
--- a/HACKING	Thu Jan 08 22:15:08 2009 +0100
+++ b/HACKING	Thu Jan 08 23:25:38 2009 +0100
@@ -82,6 +82,7 @@ The following patches are currently appl
 * icedtea-demo-swingapplet.patch: Add missing html file needed to run the demo.
 * icedtea-hotspot-dispatch.patch: Fix build failure with GCC-4.4 (PR 38725).
 * icedtea-no-precompiled.patch: Don't use precompiled header files in hotspot.
+* icedtea-includedb.patch: Add missing include.
 
 The following patches are only applied to OpenJDK6 in IcedTea6:
 
diff -r 48a808c06395 -r 6c79e6c68d05 Makefile.am
--- a/Makefile.am	Thu Jan 08 22:15:08 2009 +0100
+++ b/Makefile.am	Thu Jan 08 23:25:38 2009 +0100
@@ -650,7 +650,8 @@ ICEDTEA_PATCHES += \
 	patches/icedtea-format-warnings.patch \
 	patches/icedtea-fortify-source.patch \
 	patches/hotspot/$(HSBUILD)/icedtea-sparc-buildfixes.patch \
-	patches/hotspot/$(HSBUILD)/icedtea-hotspot-dispatch.patch
+	patches/hotspot/$(HSBUILD)/icedtea-hotspot-dispatch.patch \
+	patches/hotspot/$(HSBUILD)/icedtea-includedb.patch
 endif
 
 if !WITH_ALT_HSBUILD
diff -r 48a808c06395 -r 6c79e6c68d05 patches/hotspot/14.0b08/icedtea-includedb.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/hotspot/14.0b08/icedtea-includedb.patch	Thu Jan 08 23:25:38 2009 +0100
@@ -0,0 +1,10 @@
+--- openjdk/hotspot/src/share/vm/includeDB_core.orig	2008-11-21 17:11:18.000000000 -0700
++++ openjdk/hotspot/src/share/vm/includeDB_core	2009-01-08 14:32:58.000000000 -0700
+@@ -1314,6 +1314,7 @@
+ cppInterpreter_<arch>.cpp               interpreterRuntime.hpp
+ cppInterpreter_<arch>.cpp               interpreter.hpp
+ cppInterpreter_<arch>.cpp               interpreterGenerator.hpp
++cppInterpreter_<arch>.cpp               interfaceSupport.hpp
+ cppInterpreter_<arch>.cpp               jvmtiExport.hpp
+ cppInterpreter_<arch>.cpp               jvmtiThreadState.hpp
+ cppInterpreter_<arch>.cpp               methodDataOop.hpp


From bugzilla-daemon at icedtea.classpath.org  Thu Jan  8 14:31:24 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Thu, 08 Jan 2009 22:31:24 +0000
Subject: [Bug 277] zero fails to build from source when building without
	precompiled headers
Message-ID: <E1LL3PQ-0004eW-Am@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=277


doko at ubuntu.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #2 from doko at ubuntu.com  2009-01-08 22:31 -------
fixed, upstream error, not zero specific.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From aph at redhat.com  Fri Jan  9 01:40:13 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 09 Jan 2009 09:40:13 +0000
Subject: changeset in /hg/icedtea6: 2009-01-08 Matthias Klose <doko@ubu...
In-Reply-To: <hg.48a808c06395.1231449409.2873452341184383832@icedtea.classpath.org>
References: <hg.48a808c06395.1231449409.2873452341184383832@icedtea.classpath.org>
Message-ID: <49671B7D.2020002@redhat.com>

doko at ubuntu.com wrote:
> changeset 48a808c06395 in /hg/icedtea6
> details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=48a808c06395
> description:
> 	2009-01-08  Matthias Klose  <doko at ubuntu.com>
> 
> 	        * patches/hotspot/14.0b08/icedtea-no-precompiled.patch: Don't use
> 	        precompiled header files in hotspot.
> 	        * HACKING: Document the above.

Has there been any discussion about this?  I can't remember seeing
any.  This is a regression for those of us working on HotSpot.

Andrew.



From doko at ubuntu.com  Fri Jan  9 01:44:55 2009
From: doko at ubuntu.com (Matthias Klose)
Date: Fri, 09 Jan 2009 10:44:55 +0100
Subject: changeset in /hg/icedtea6: 2009-01-08 Matthias Klose <doko@ubu...
In-Reply-To: <49671B7D.2020002@redhat.com>
References: <hg.48a808c06395.1231449409.2873452341184383832@icedtea.classpath.org>
	<49671B7D.2020002@redhat.com>
Message-ID: <49671C97.5010003@ubuntu.com>

Andrew Haley schrieb:
> doko at ubuntu.com wrote:
>> changeset 48a808c06395 in /hg/icedtea6
>> details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=48a808c06395
>> description:
>> 	2009-01-08  Matthias Klose  <doko at ubuntu.com>
>>
>> 	        * patches/hotspot/14.0b08/icedtea-no-precompiled.patch: Don't use
>> 	        precompiled header files in hotspot.
>> 	        * HACKING: Document the above.
> 
> Has there been any discussion about this?  I can't remember seeing
> any.  This is a regression for those of us working on HotSpot.

No, the patch is not applied, just checked in for convenience. Does this require
discussion?

  Matthias


From aph at redhat.com  Fri Jan  9 01:49:36 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 09 Jan 2009 09:49:36 +0000
Subject: changeset in /hg/icedtea6: 2009-01-08 Matthias Klose <doko@ubu...
In-Reply-To: <49671C97.5010003@ubuntu.com>
References: <hg.48a808c06395.1231449409.2873452341184383832@icedtea.classpath.org>
	<49671B7D.2020002@redhat.com> <49671C97.5010003@ubuntu.com>
Message-ID: <49671DB0.4050005@redhat.com>

Matthias Klose wrote:
> Andrew Haley schrieb:
>> doko at ubuntu.com wrote:
>>> changeset 48a808c06395 in /hg/icedtea6
>>> details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=48a808c06395
>>> description:
>>> 	2009-01-08  Matthias Klose  <doko at ubuntu.com>
>>>
>>> 	        * patches/hotspot/14.0b08/icedtea-no-precompiled.patch: Don't use
>>> 	        precompiled header files in hotspot.
>>> 	        * HACKING: Document the above.
>> Has there been any discussion about this?  I can't remember seeing
>> any.  This is a regression for those of us working on HotSpot.
> 
> No, the patch is not applied, just checked in for convenience. Does this require
> discussion?

In general, changes should be discussed.

As this one is not applied I suppose it's not a substantive change.
However, I would really like to know what problem it's supposed to
solve.

Andrew.


From doko at ubuntu.com  Fri Jan  9 01:59:42 2009
From: doko at ubuntu.com (Matthias Klose)
Date: Fri, 09 Jan 2009 10:59:42 +0100
Subject: changeset in /hg/icedtea6: 2009-01-08 Matthias Klose <doko@ubu...
In-Reply-To: <49671DB0.4050005@redhat.com>
References: <hg.48a808c06395.1231449409.2873452341184383832@icedtea.classpath.org>
	<49671B7D.2020002@redhat.com> <49671C97.5010003@ubuntu.com>
	<49671DB0.4050005@redhat.com>
Message-ID: <4967200E.8060005@ubuntu.com>

Andrew Haley schrieb:
> Matthias Klose wrote:
>> Andrew Haley schrieb:
>>> doko at ubuntu.com wrote:
>>>> changeset 48a808c06395 in /hg/icedtea6
>>>> details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=48a808c06395
>>>> description:
>>>> 	2009-01-08  Matthias Klose  <doko at ubuntu.com>
>>>>
>>>> 	        * patches/hotspot/14.0b08/icedtea-no-precompiled.patch: Don't use
>>>> 	        precompiled header files in hotspot.
>>>> 	        * HACKING: Document the above.
>>> Has there been any discussion about this?  I can't remember seeing
>>> any.  This is a regression for those of us working on HotSpot.
>> No, the patch is not applied, just checked in for convenience. Does this require
>> discussion?
> 
> In general, changes should be discussed.
> 
> As this one is not applied I suppose it's not a substantive change.
> However, I would really like to know what problem it's supposed to
> solve.

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-January/004396.html
did show the need to build without precompiled headers. instead of having
everybody to figure out how to do this, I checked in the patch. Sure this could
be moved to a patches/contrib or patches/unused directory as well.


From gbenson at redhat.com  Fri Jan  9 02:01:28 2009
From: gbenson at redhat.com (Gary Benson)
Date: Fri, 9 Jan 2009 10:01:28 +0000
Subject: changeset in /hg/icedtea6: 2009-01-08 Matthias Klose <doko@ubu...
In-Reply-To: <49671DB0.4050005@redhat.com>
References: <hg.48a808c06395.1231449409.2873452341184383832@icedtea.classpath.org>
	<49671B7D.2020002@redhat.com> <49671C97.5010003@ubuntu.com>
	<49671DB0.4050005@redhat.com>
Message-ID: <20090109100128.GA3174@redhat.com>

Andrew Haley wrote:
> Matthias Klose wrote:
> >  Andrew Haley schrieb:
> > > doko at ubuntu.com wrote:
> > > > changeset 48a808c06395 in /hg/icedtea6
> > > > details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=48a808c06395
> > > > description:
> > > > 	2009-01-08  Matthias Klose  <doko at ubuntu.com>
> > > >
> > > > 	        * patches/hotspot/14.0b08/icedtea-no-precompiled.patch: Don't use
> > > > 	        precompiled header files in hotspot.
> > > > 	        * HACKING: Document the above.
> > >
> > > Has there been any discussion about this?  I can't remember
> > > seeing any.  This is a regression for those of us working on
> > > HotSpot.
> > 
> > No, the patch is not applied, just checked in for
> > convenience. Does this require discussion?
> 
> In general, changes should be discussed.
> 
> As this one is not applied I suppose it's not a substantive change.
> However, I would really like to know what problem it's supposed to
> solve.

FWIW I've always found building without precompiled headers to be a
world of pain...

Cheers,
Gary

-- 
http://gbenson.net/


From aph at redhat.com  Fri Jan  9 02:04:37 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 09 Jan 2009 10:04:37 +0000
Subject: changeset in /hg/icedtea6: 2009-01-08 Matthias Klose <doko@ubu...
In-Reply-To: <4967200E.8060005@ubuntu.com>
References: <hg.48a808c06395.1231449409.2873452341184383832@icedtea.classpath.org>
	<49671B7D.2020002@redhat.com> <49671C97.5010003@ubuntu.com>
	<49671DB0.4050005@redhat.com> <4967200E.8060005@ubuntu.com>
Message-ID: <49672135.8070205@redhat.com>

Matthias Klose wrote:
> Andrew Haley schrieb:
>> Matthias Klose wrote:
>>> Andrew Haley schrieb:
>>>> doko at ubuntu.com wrote:
>>>>> changeset 48a808c06395 in /hg/icedtea6
>>>>> details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=48a808c06395
>>>>> description:
>>>>> 	2009-01-08  Matthias Klose  <doko at ubuntu.com>
>>>>>
>>>>> 	        * patches/hotspot/14.0b08/icedtea-no-precompiled.patch: Don't use
>>>>> 	        precompiled header files in hotspot.
>>>>> 	        * HACKING: Document the above.
>>>> Has there been any discussion about this?  I can't remember seeing
>>>> any.  This is a regression for those of us working on HotSpot.
>>> No, the patch is not applied, just checked in for convenience. Does this require
>>> discussion?
>> In general, changes should be discussed.
>>
>> As this one is not applied I suppose it's not a substantive change.
>> However, I would really like to know what problem it's supposed to
>> solve.
> 
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-January/004396.html
> did show the need to build without precompiled headers. instead of having
> everybody to figure out how to do this, I checked in the patch. Sure this could
> be moved to a patches/contrib or patches/unused directory as well.

Ah, OK, it's just a workaround for a compiler bug.

I'm not wildly keen on putting patches in contrib, for what it's worth.
If it's useful to you it'll probably be useful to others too.

Please don't confuse my request for this patch to be explained with
a request for it to be removed.

Andrew.


From gbenson at redhat.com  Fri Jan  9 04:19:44 2009
From: gbenson at redhat.com (Gary Benson)
Date: Fri, 09 Jan 2009 12:19:44 +0000
Subject: changeset in /hg/icedtea6: 2009-01-09  Gary Benson  <gbenson@red...
Message-ID: <hg.8ed37e6cc2df.1231503584.2873452341184383832@icedtea.classpath.org>

changeset 8ed37e6cc2df in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=8ed37e6cc2df
description:
	2009-01-09  Gary Benson  <gbenson at redhat.com>

		* patches/icedtea-cc-interp-jvmti.patch: Also disable pop_frame.

diffstat:

2 files changed, 11 insertions(+), 10 deletions(-)
ChangeLog                             |    4 ++++
patches/icedtea-cc-interp-jvmti.patch |   17 +++++++----------

diffs (48 lines):

diff -r 6c79e6c68d05 -r 8ed37e6cc2df ChangeLog
--- a/ChangeLog	Thu Jan 08 23:25:38 2009 +0100
+++ b/ChangeLog	Fri Jan 09 07:19:20 2009 -0500
@@ -1,3 +1,7 @@ 2009-01-08  Matthias Klose  <doko at ubuntu
+2009-01-09  Gary Benson  <gbenson at redhat.com>
+
+	* patches/icedtea-cc-interp-jvmti.patch: Also disable pop_frame.
+
 2009-01-08  Matthias Klose  <doko at ubuntu.com>
 
 	PR icedtea/277
diff -r 6c79e6c68d05 -r 8ed37e6cc2df patches/icedtea-cc-interp-jvmti.patch
--- a/patches/icedtea-cc-interp-jvmti.patch	Thu Jan 08 23:25:38 2009 +0100
+++ b/patches/icedtea-cc-interp-jvmti.patch	Fri Jan 09 07:19:20 2009 -0500
@@ -1,26 +1,23 @@
 --- openjdk/hotspot/src/share/vm/prims/jvmtiManageCapabilities.cpp	2008-12-24 12:01:18.000000000 +0000
 +++ openjdk/hotspot/src/share/vm/prims/jvmtiManageCapabilities.cpp	2008-12-24 12:00:29.000000000 +0000
-@@ -84,7 +84,11 @@
+@@ -84,7 +84,9 @@
  
    memset(&jc, 0, sizeof(jc));
    jc.can_get_bytecodes = 1;
-+#ifdef CC_INTERP
-+  jc.can_signal_thread = 0;
-+#else
++#ifndef CC_INTERP
    jc.can_signal_thread = 1;
-+#endif // CC_INTERP
++#endif // !CC_INTERP
    jc.can_get_source_file_name = 1;
    jc.can_get_line_numbers = 1;
    jc.can_get_synthetic_attribute = 1;
-@@ -116,7 +120,11 @@
+@@ -115,8 +117,10 @@
+   jvmtiCapabilities jc;
  
    memset(&jc, 0, sizeof(jc));
++#ifndef CC_INTERP
    jc.can_pop_frame = 1;
-+#ifdef CC_INTERP
-+  jc.can_force_early_return = 0;
-+#else
    jc.can_force_early_return = 1;
-+#endif // CC_INTERP
++#endif // !CC_INTERP
    jc.can_get_source_debug_extension = 1;
    jc.can_access_local_variables = 1;
    jc.can_maintain_original_method_order = 1;


From gbenson at redhat.com  Fri Jan  9 04:23:08 2009
From: gbenson at redhat.com (Gary Benson)
Date: Fri, 09 Jan 2009 12:23:08 +0000
Subject: changeset in /hg/icedtea6: 2009-01-09  Gary Benson  <gbenson@red...
Message-ID: <hg.972ccbe95125.1231503788.2873452341184383832@icedtea.classpath.org>

changeset 972ccbe95125 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=972ccbe95125
description:
	2009-01-09  Gary Benson  <gbenson at redhat.com>

		* ports/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp
		(CppInterpreter::main_loop): Catch unhandled messages.

diffstat:

2 files changed, 8 insertions(+)
ChangeLog                                             |    5 +++++
ports/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp |    3 +++

diffs (25 lines):

diff -r 8ed37e6cc2df -r 972ccbe95125 ChangeLog
--- a/ChangeLog	Fri Jan 09 07:19:20 2009 -0500
+++ b/ChangeLog	Fri Jan 09 07:21:33 2009 -0500
@@ -1,3 +1,8 @@ 2009-01-09  Gary Benson  <gbenson at redhat
+2009-01-09  Gary Benson  <gbenson at redhat.com>
+
+	* ports/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp
+	(CppInterpreter::main_loop): Catch unhandled messages.
+
 2009-01-09  Gary Benson  <gbenson at redhat.com>
 
 	* patches/icedtea-cc-interp-jvmti.patch: Also disable pop_frame.
diff -r 8ed37e6cc2df -r 972ccbe95125 ports/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp
--- a/ports/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp	Fri Jan 09 07:19:20 2009 -0500
+++ b/ports/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp	Fri Jan 09 07:21:33 2009 -0500
@@ -156,6 +156,9 @@ void CppInterpreter::main_loop(int recur
       assert(HAS_PENDING_EXCEPTION, "should do");
       break;
     }
+    else {
+      ShouldNotReachHere();
+    }
   }
 
  unwind_and_return:


From gbenson at redhat.com  Fri Jan  9 04:23:08 2009
From: gbenson at redhat.com (Gary Benson)
Date: Fri, 09 Jan 2009 12:23:08 +0000
Subject: changeset in /hg/icedtea6: 2009-01-09  Gary Benson  <gbenson@red...
Message-ID: <hg.bc82fc344da8.1231503788.2873452341184383832@icedtea.classpath.org>

changeset bc82fc344da8 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=bc82fc344da8
description:
	2009-01-09  Gary Benson  <gbenson at redhat.com>

		* contrib/mixtec-sleep-on-bomb.patch: New file.

diffstat:

2 files changed, 41 insertions(+)
ChangeLog                          |    4 +++
contrib/mixtec-sleep-on-bomb.patch |   37 ++++++++++++++++++++++++++++++++++++

diffs (52 lines):

diff -r 972ccbe95125 -r bc82fc344da8 ChangeLog
--- a/ChangeLog	Fri Jan 09 07:21:33 2009 -0500
+++ b/ChangeLog	Fri Jan 09 07:22:45 2009 -0500
@@ -1,3 +1,7 @@ 2009-01-09  Gary Benson  <gbenson at redhat
+2009-01-09  Gary Benson  <gbenson at redhat.com>
+
+	* contrib/mixtec-sleep-on-bomb.patch: New file.
+
 2009-01-09  Gary Benson  <gbenson at redhat.com>
 
 	* ports/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp
diff -r 972ccbe95125 -r bc82fc344da8 contrib/mixtec-sleep-on-bomb.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/contrib/mixtec-sleep-on-bomb.patch	Fri Jan 09 07:22:45 2009 -0500
@@ -0,0 +1,37 @@
+This patch causes the VM to drop into an infinite sleep if the fatal
+error handler is invoked.  This is handy for getting gdb attached in
+situations where you couldn't usually, when the VM is invoked by the
+JCK for example.
+
+diff -r b0dd0cbb5c04 openjdk/hotspot/src/os/linux/vm/os_linux.cpp
+--- openjdk/hotspot/src/os/linux/vm/os_linux.cpp	Wed Jan 07 17:45:25 2009
++++ openjdk/hotspot/src/os/linux/vm/os_linux.cpp	Thu Jan 08 11:51:14 2009
+@@ -1466,6 +1466,7 @@
+ // called from signal handler. Before adding something to os::abort(), make
+ // sure it is async-safe and can handle partially initialized VM.
+ void os::abort(bool dump_core) {
++  os::infinite_sleep();
+   os::shutdown();
+   if (dump_core) {
+ #ifndef PRODUCT
+@@ -1484,6 +1485,7 @@
+ 
+ // Die immediately, no exit hook, no abort hook, no cleanup.
+ void os::die() {
++  os::infinite_sleep();
+   // _exit() on LinuxThreads only kills current thread
+   ::abort();
+ }
+@@ -2873,6 +2875,12 @@
+ 
+ // Sleep forever; naked call to OS-specific sleep; use with CAUTION
+ void os::infinite_sleep() {
++  fdStream out(defaultStream::output_fd());
++  char buf[16];
++  jio_snprintf(buf, sizeof(buf), UINTX_FORMAT, os::current_thread_id());
++  out.print_raw("thread ");
++  out.print_raw(buf);
++  out.print_raw(" going to sleep...");
+   while (true) {    // sleep forever ...
+     ::sleep(100);   // ... 100 seconds at a time
+   }


From bugzilla-daemon at icedtea.classpath.org  Fri Jan  9 06:16:39 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Fri, 09 Jan 2009 14:16:39 +0000
Subject: [Bug 280] New: icedtea-bin-3.3.0-r1 fails to open HP WebAdmin
	interface on HP4050n
Message-ID: <E1LLIAB-0005sB-AN@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=280

           Summary: icedtea-bin-3.3.0-r1 fails to open HP WebAdmin interface
                    on HP4050n
           Product: IcedTea
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: retrievil at mailinator.com


Upon installation of icedtea-3.3.0-r1 I am having problems accessing the admin
interface of a networked printer, it is old and the problems may be related to
verifying .jar files.

I am running Gentoo Linux x64 and the errors are as follows, an output from
Firefox 3.0.5:
----------------------------------------------------------------
ICEDTEAPLUGIN_DEBUG = (null)
Initializing JVM...
NOT IMPLEMENTED: virtual nsresult IcedTeaPluginInstance::Start()
NOT IMPLEMENTED: virtual nsresult IcedTeaPluginInstance::Start()
NOT IMPLEMENTED: virtual nsresult IcedTeaPluginInstance::Start()
NOT IMPLEMENTED: virtual nsresult IcedTeaPluginInstance::Start()
Jar string: bob
jars length: 1
JNLPRuntime already initialized
java.lang.NullPointerException
        at net.sourceforge.jnlp.tools.JarSigner.verifyJars(JarSigner.java:192)
        at
net.sourceforge.jnlp.runtime.JNLPClassLoader.verifyJars(JNLPClassLoader.java:609)
        at
net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:302)
        at
net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:134)
        at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:191)
        at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
        at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
netx: Initialization Error: Could not initialize applet.
(net.sourceforge.jnlp.LaunchException Fatal: Initialization Error: A fatal
error occurred while trying to verify jars.)
netx: Initialization Error: Could not initialize applet.
(net.sourceforge.jnlp.LaunchException Fatal: Initialization Error: A fatal
error occurred while trying to verify jars.)
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not
initialize applet.
        at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:472)
        at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A
fatal error occurred while trying to verify jars.
        at
net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:308)
        at
net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:134)
        at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:191)
        at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
        ... 2 more
Caused by: 
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A fatal
error occurred while trying to verify jars.
        at
net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:308)
        at
net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:134)
        at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:191)
        at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:445)
        at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:418)
        at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:597)
IcedTeaPlugin.cc:3809: Error: Failed to flush bytes to output channel: Broken
pipe
-------------------------------------------------

Also, when I exit firefox, it stalls, and I have to Ctrl-C (or in worst case,
Ctrl-Z and kill -9) to get it to exit completely.

This is output after I exit firefox:

-------------------------------------------------
NOT IMPLEMENTED: virtual nsresult IcedTeaPluginInstance::Stop()
NOT IMPLEMENTED: virtual nsresult IcedTeaPluginInstance::Stop()
-------------------------------------------------

What to do?


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Fri Jan  9 06:20:23 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Fri, 09 Jan 2009 14:20:23 +0000
Subject: [Bug 280] icedtea-bin-3.3.0-r1 fails to open HP WebAdmin interface on
	HP4050n
Message-ID: <E1LLIDn-0005sQ-4s@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=280





------- Comment #1 from retrievil at mailinator.com  2009-01-09 14:20 -------
This is the result of "java -version":

java version "1.6.0_0"
IcedTea6 1.3.1 (Gentoo) Runtime Environment (build 1.6.0_0-b12)
OpenJDK 64-Bit Server VM (build 10.0-b19, mixed mode)


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From omajid at redhat.com  Fri Jan  9 08:55:17 2009
From: omajid at redhat.com (Omair Majid)
Date: Fri, 09 Jan 2009 16:55:17 +0000
Subject: changeset in /hg/icedtea6: 2009-01-09  Omair Majid  <omajid@redh...
Message-ID: <hg.508839ea3465.1231520117.2873452341184383832@icedtea.classpath.org>

changeset 508839ea3465 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=508839ea3465
description:
	2009-01-09  Omair Majid  <omajid at redhat.com>

	    * patches/icedtea-awt-window-size.patch: New file. Fix X11 window size
	    calculation.
	    * Makefile.am: Apply patch.
	    * HACKING: Document the above.

diffstat:

4 files changed, 77 insertions(+), 1 deletion(-)
ChangeLog                             |    7 +++
HACKING                               |    1 
Makefile.am                           |    3 -
patches/icedtea-awt-window-size.patch |   67 +++++++++++++++++++++++++++++++++

diffs (109 lines):

diff -r bc82fc344da8 -r 508839ea3465 ChangeLog
--- a/ChangeLog	Fri Jan 09 07:22:45 2009 -0500
+++ b/ChangeLog	Fri Jan 09 11:53:07 2009 -0500
@@ -1,3 +1,10 @@ 2009-01-09  Gary Benson  <gbenson at redhat
+2009-01-09  Omair Majid  <omajid at redhat.com>
+
+	* patches/icedtea-awt-window-size.patch: New file. Fix X11 window size
+	calculation.
+	* Makefile.am: Apply patch.
+	* HACKING: Document the above.
+
 2009-01-09  Gary Benson  <gbenson at redhat.com>
 
 	* contrib/mixtec-sleep-on-bomb.patch: New file.
diff -r bc82fc344da8 -r 508839ea3465 HACKING
--- a/HACKING	Fri Jan 09 07:22:45 2009 -0500
+++ b/HACKING	Fri Jan 09 11:53:07 2009 -0500
@@ -83,6 +83,7 @@ The following patches are currently appl
 * icedtea-hotspot-dispatch.patch: Fix build failure with GCC-4.4 (PR 38725).
 * icedtea-no-precompiled.patch: Don't use precompiled header files in hotspot.
 * icedtea-includedb.patch: Add missing include.
+* icedtea-awt-window-size.patch: Fix X11 window size calculation (S6721088).
 
 The following patches are only applied to OpenJDK6 in IcedTea6:
 
diff -r bc82fc344da8 -r 508839ea3465 Makefile.am
--- a/Makefile.am	Fri Jan 09 07:22:45 2009 -0500
+++ b/Makefile.am	Fri Jan 09 11:53:07 2009 -0500
@@ -691,7 +691,8 @@ ICEDTEA_PATCHES += \
 ICEDTEA_PATCHES += \
 	$(DISTRIBUTION_PATCHES) \
 	patches/icedtea-a11y-property-change.patch \
-	patches/icedtea-demo-swingapplet.patch
+	patches/icedtea-demo-swingapplet.patch \
+	patches/icedtea-awt-window-size.patch
 
 stamps/extract.stamp: stamps/download.stamp
 if OPENJDK_SRC_DIR_FOUND
diff -r bc82fc344da8 -r 508839ea3465 patches/icedtea-awt-window-size.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/icedtea-awt-window-size.patch	Fri Jan 09 11:53:07 2009 -0500
@@ -0,0 +1,67 @@
+--- openjdk/jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java.orig	2009-01-08 16:53:54.000000000 -0500
++++ openjdk/jdk/src/solaris/classes/sun/awt/X11/XDecoratedPeer.java	2009-01-08 16:54:08.000000000 -0500
+@@ -478,7 +478,10 @@
+             // do nothing but accept it.
+             Rectangle reqBounds = newDimensions.getBounds();
+             Rectangle newBounds = constrainBounds(reqBounds.x, reqBounds.y, reqBounds.width, reqBounds.height);
+-            newDimensions = new WindowDimensions(newBounds, newDimensions.getInsets(), newDimensions.isClientSizeSet());
++            Insets insets = newDimensions.getInsets();
++            Rectangle fixedBounds = new Rectangle(newBounds.x, newBounds.y, newBounds.width - insets.left - insets.right,
++                    newBounds.height - insets.top - insets.bottom);
++            newDimensions = new WindowDimensions(fixedBounds, insets, newDimensions.isClientSizeSet());
+         }
+         XToolkit.awtLock();
+         try {
+--- /dev/null	2009-01-09 04:32:08.413012246 -0500
++++ openjdk/jdk/test/java/awt/Frame/FrameSize/TestFrameSize.java	2009-01-09 11:30:54.000000000 -0500
+@@ -0,0 +1,50 @@
++/*
++  @test
++  @bug 6721088
++  @summary X11 Window sizes should be what we set them to
++  @author Omair Majid <omajid at redhat.com>
++  @run main TestFrameSize
++ */
++
++import java.awt.Dimension;
++import java.awt.Frame;
++
++/**
++ * TestFrameSize.java
++ * 
++ * Summary: test that X11 Awt windows are drawn with correct sizes
++ * 
++ * Test fails if size of window is wrong
++ */
++
++public class TestFrameSize {
++
++	static Dimension desiredDimensions = new Dimension(200, 200);
++	static int ERROR_MARGIN = 15;
++	static Frame mainWindow;
++
++	public static void drawGui() {
++		mainWindow = new Frame("");
++		mainWindow.setPreferredSize(desiredDimensions);
++		mainWindow.pack();
++		// mainWindow.setVisible(true);
++
++		Dimension actualDimensions = mainWindow.getSize();
++		// System.out.println(desiredDimensions);
++		// System.out.println(actualDimensions);
++		if (Math.abs(actualDimensions.height - desiredDimensions.height) > ERROR_MARGIN) {
++			throw new RuntimeException("Incorrect widow size");
++		}
++
++	}
++
++	public static void main(String[] args) {
++		try {
++			drawGui();
++		} finally {
++			if (mainWindow != null) {
++				mainWindow.dispose();
++			}
++		}
++	}
++}


From ekrichardson at gmail.com  Fri Jan  9 10:10:54 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Fri, 9 Jan 2009 10:10:54 -0800
Subject: Icedtea 7 make patch problem
Message-ID: <860cb0120901091010h20d5a9cy133bc3e3744df4f2@mail.gmail.com>

Hello,

I am on PowerPC MacOSX and got much further than yesterday. If there is
other info needed I can post it tonight.

Checking patches/hotspot/original/icedtea-version.patch
Applying patches/hotspot/original/icedtea-version.patch
patching file openjdk/hotspot/make/linux/makefiles/vm.make
patching file openjdk/hotspot/src/share/vm/utilities/vmError.cpp
Hunk #1 succeeded at 170 (offset 5 lines).
Hunk #2 succeeded at 347 (offset 7 lines).
Checking patches/icedtea-copy-plugs.patch
1 out of 3 hunks FAILED -- saving rejects to file
openjdk/jdk/make/common/internal/BinaryPlugs.gmk.rej
ERROR patch patches/icedtea-copy-plugs.patch FAILED!
WARNING make clean-patch before retrying a fix
make: *** [stamps/patch.stamp] Error 2

Thanks for any ideas,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090109/a798f36d/attachment.html 

From ekrichardson at gmail.com  Fri Jan  9 10:13:50 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Fri, 9 Jan 2009 10:13:50 -0800
Subject: Problem Compiling Java
In-Reply-To: <fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
Message-ID: <860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>

Michael,

This fixed the compile problem. I still get this error but it passes by it.

incorrect classpath: hotspot-tools/com/sun/codemodel/internal/ClassType.java

Eric

On Thu, Jan 8, 2009 at 4:14 AM, Michael Franz <mvfranz at gmail.com> wrote:

> Eric,
>
> You can edit your /opt/local/bin/ecj scrip to have a larger memory
> setting.  I use -Xmx768m.
>
> java -Xmx768M org.eclipse.jdt.internal.compiler.batch.Main "$@"
>
> I cannot not explain all the details, but since ecj is a shell script it
> does not handle passing parameters all that well to java.  I have found
> other people's attempts and I have tried my self.  There is all kinds of fun
> trying to deal with the shell expanding parameters when they need to be
> passed verbatim.
>
> Michael
>
> On Thu, Jan 8, 2009 at 4:22 AM, Christian Thalinger <
> christian.thalinger at gmail.com> wrote:
>
>> On Wed, 2009-01-07 at 20:56 -0800, Eric Richardson wrote:
>> > I changed the Makefile to get more memory.
>>
>> > patrizia-imac-g5:icedtea6 eric$ make
>> > if ! test -d /Users/eric/java/icedtea6/bootstrap/jdk1.6.0 ; \
>> >     then \
>> >       /opt/local/bin/ecj -nowarn -J-Xmx4096m -g -d lib/hotspot-tools \
>> >             -source 1.5 \
>> >             -sourcepath \
>> >
>> >
>> 'hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/Users/eric/java/icedtea6/generated:/Users/eric/java/icedtea6/rt'
>> \
>> >             -bootclasspath '' @hotspot-tools-source-files.txt ; \
>> >     else \
>> >       /Users/eric/java/icedtea6/bootstrap/jdk1.6.0/bin/javac
>> > -J-Xmx4096m -g \
>>
>> Is bootstrap/jdk1.6.0/bin/javac using ECJ or Apple's Javac?  If it's
>> ECJ, -J options are ignored.
>>
>> - Christian
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090109/99730cad/attachment.html 

From ekrichardson at gmail.com  Fri Jan  9 10:29:07 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Fri, 9 Jan 2009 10:29:07 -0800
Subject: Icedtea 6 BSD experimentation PowerPC Mac
Message-ID: <860cb0120901091029j1427aftab6913c52e61f4@mail.gmail.com>

Hello,

I got the error below compiling. I haven't gotten this far yet with icetea7.
I tried to clear the errors by doing the following.

cp Defs-bsd.gmk /Users/eric/java/icedtea6/openjdk/jdk/make/common
(from Icedtea7)
make ARCH=ppc ARCH_DATA_MODEL=32 PLATFORM=bsd

It helped a bit. I wondering here based on the errors below about missing
ARCH etc. below if ARCH is needed to be specified to make or do I have a
detection problem?

Eric


touch stamps/cacao.stamp
/usr/bin/make \
      "ALT_JDK_IMPORT_PATH=/Users/eric/java/icedtea6/bootstrap/jdk1.6.0"
"ANT_HOME=/usr/share/ant" "BUILD_NUMBER=b14" "JDK_UPDATE_VERSION=0"
"JRE_RELEASE_VERSION=1.6.0_0-b14" "MILESTONE=fcs" "LANG=C"
"PATH=/Users/eric/java/icedtea6/bootstrap/jdk1.6.0/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH"
"ALT_BOOTDIR=/Users/eric/java/icedtea6/bootstrap/jdk1.6.0"
"ALT_BINARY_PLUGS_PATH=/Users/eric/java/icedtea6/bootstrap/jdk1.7.0"
"BUILD_ARCH_DIR=ppc"
"ICEDTEA_RT=/Users/eric/java/icedtea6/bootstrap/jdk1.7.0/jre/lib/rt-closed.jar"
"ICEDTEA_BUILD_DIR=/Users/eric/java/icedtea6/openjdk-ecj/control/build/linux-ppc/"
"ICEDTEA_CLS_DIR=/Users/eric/java/icedtea6/openjdk-ecj/control/build/linux-ppc/classes"
"ICEDTEA_ENDORSED_DIR=/Users/eric/java/icedtea6/bootstrap/jdk1.6.0/lib/endorsed"
"ENDORSED=-Djava.endorsed.dirs=/Users/eric/java/icedtea6/bootstrap/jdk1.6.0/lib/endorsed"
"BOOTCLASSPATH_CLS_RT=-bootclasspath
/Users/eric/java/icedtea6/openjdk-ecj/control/build/linux-ppc/classes:/Users/eric/java/icedtea6/bootstrap/jdk1.7.0/jre/lib/rt-closed.jar"
"BOOTCLASSPATH_CLS=-bootclasspath
/Users/eric/java/icedtea6/openjdk-ecj/control/build/linux-ppc/classes"
"BOOTCLASSPATH_RT_LIBGCJ=-bootclasspath
/Users/eric/java/icedtea6/bootstrap/jdk1.7.0/jre/lib/rt-closed.jar:/Library/Java/Home/jre/lib/rt.jar"
"CLASSPATH=" "LD_LIBRARY_PATH="
"GENSRCDIR=/Users/eric/java/icedtea6/generated" "ICEDTEA_CORE_BUILD=yes"
"ICEDTEA_ZERO_BUILD=yes" "ICEDTEA_SHARK_BUILD=" "ZERO_LIBARCH=ppc"
"ZERO_BITSPERWORD=32" "ZERO_ENDIANNESS=big" "ZERO_ARCHDEF=PPC"
"ZERO_ARCHFLAG=-m32" "LIBFFI_CFLAGS=-I/opt/local/lib/libffi-3.0.6/include  "
"LIBFFI_LIBS=-L/opt/local/lib -lffi  " "LLVM_CFLAGS=" "LLVM_LDFLAGS="
"LLVM_LIBS=" "FREETYPE2_HEADERS=-I/usr/X11/include/freetype2
-I/usr/X11/include  " "FT2_LIB=-Wl,-framework,CoreServices
-Wl,-framework,ApplicationServices -L/usr/X11/lib -lfreetype -lz  "
"ALT_PARALLEL_COMPILE_JOBS=2" "HOTSPOT_BUILD_JOBS=2" "JAVAC="
"RHINO_JAR=/Users/eric/java-libs/js-engine.jar" "JAR_KNOWS_ATFILE=1"
"JAR_KNOWS_J_OPTIONS=1" "JAR_ACCEPTS_STDIN_LIST="    \
      -C openjdk-ecj/control/make \

../../jdk/make/common/shared/Defs.gmk:157: "WARNING: Value of ARCH cannot be
empty, will use ''"
../../jdk/make/common/shared/Defs.gmk:157: "WARNING: Value of
ARCH_DATA_MODEL cannot be empty, will use ''"
../../jdk/make/common/shared/Defs.gmk:157: "WARNING: Value of PLATFORM
cannot be empty, will use ''"
../../jdk/make/common/shared/Defs.gmk:330:
../../jdk/make/common/shared/Defs-.gmk: No such file or directory
../../jdk/make/common/shared/Compiler.gmk:46:
../../jdk/make/common/shared/Compiler-.gmk: No such file or directory
make[1]: *** No rule to make target
`../../jdk/make/common/shared/Compiler-.gmk'.  Stop.
make: *** [stamps/icedtea-ecj.stamp] Error 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090109/4310ef51/attachment.html 

From gnu_andrew at member.fsf.org  Fri Jan  9 13:05:56 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 9 Jan 2009 21:05:56 +0000
Subject: Icedtea 6 BSD experimentation PowerPC Mac
In-Reply-To: <860cb0120901091029j1427aftab6913c52e61f4@mail.gmail.com>
References: <860cb0120901091029j1427aftab6913c52e61f4@mail.gmail.com>
Message-ID: <17c6771e0901091305n5c263387md72aaaf3bb572c8e@mail.gmail.com>

2009/1/9 Eric Richardson <ekrichardson at gmail.com>:
> Hello,
>
> I got the error below compiling. I haven't gotten this far yet with icetea7.
> I tried to clear the errors by doing the following.
>
> cp Defs-bsd.gmk /Users/eric/java/icedtea6/openjdk/jdk/make/common
> (from Icedtea7)
> make ARCH=ppc ARCH_DATA_MODEL=32 PLATFORM=bsd
>
> It helped a bit. I wondering here based on the errors below about missing
> ARCH etc. below if ARCH is needed to be specified to make or do I have a
> detection problem?
>
> Eric
>
>
> touch stamps/cacao.stamp
> /usr/bin/make \
>       "ALT_JDK_IMPORT_PATH=/Users/eric/java/icedtea6/bootstrap/jdk1.6.0"
> "ANT_HOME=/usr/share/ant" "BUILD_NUMBER=b14" "JDK_UPDATE_VERSION=0"
> "JRE_RELEASE_VERSION=1.6.0_0-b14" "MILESTONE=fcs" "LANG=C"
> "PATH=/Users/eric/java/icedtea6/bootstrap/jdk1.6.0/bin:/usr/bin:/bin:/usr/sbin:/sbin:$PATH"
> "ALT_BOOTDIR=/Users/eric/java/icedtea6/bootstrap/jdk1.6.0"
> "ALT_BINARY_PLUGS_PATH=/Users/eric/java/icedtea6/bootstrap/jdk1.7.0"
> "BUILD_ARCH_DIR=ppc"
> "ICEDTEA_RT=/Users/eric/java/icedtea6/bootstrap/jdk1.7.0/jre/lib/rt-closed.jar"
> "ICEDTEA_BUILD_DIR=/Users/eric/java/icedtea6/openjdk-ecj/control/build/linux-ppc/"
> "ICEDTEA_CLS_DIR=/Users/eric/java/icedtea6/openjdk-ecj/control/build/linux-ppc/classes"
> "ICEDTEA_ENDORSED_DIR=/Users/eric/java/icedtea6/bootstrap/jdk1.6.0/lib/endorsed"
> "ENDORSED=-Djava.endorsed.dirs=/Users/eric/java/icedtea6/bootstrap/jdk1.6.0/lib/endorsed"
> "BOOTCLASSPATH_CLS_RT=-bootclasspath
> /Users/eric/java/icedtea6/openjdk-ecj/control/build/linux-ppc/classes:/Users/eric/java/icedtea6/bootstrap/jdk1.7.0/jre/lib/rt-closed.jar"
> "BOOTCLASSPATH_CLS=-bootclasspath
> /Users/eric/java/icedtea6/openjdk-ecj/control/build/linux-ppc/classes"
> "BOOTCLASSPATH_RT_LIBGCJ=-bootclasspath
> /Users/eric/java/icedtea6/bootstrap/jdk1.7.0/jre/lib/rt-closed.jar:/Library/Java/Home/jre/lib/rt.jar"
> "CLASSPATH=" "LD_LIBRARY_PATH="
> "GENSRCDIR=/Users/eric/java/icedtea6/generated" "ICEDTEA_CORE_BUILD=yes"
> "ICEDTEA_ZERO_BUILD=yes" "ICEDTEA_SHARK_BUILD=" "ZERO_LIBARCH=ppc"
> "ZERO_BITSPERWORD=32" "ZERO_ENDIANNESS=big" "ZERO_ARCHDEF=PPC"
> "ZERO_ARCHFLAG=-m32" "LIBFFI_CFLAGS=-I/opt/local/lib/libffi-3.0.6/include  "
> "LIBFFI_LIBS=-L/opt/local/lib -lffi  " "LLVM_CFLAGS=" "LLVM_LDFLAGS="
> "LLVM_LIBS=" "FREETYPE2_HEADERS=-I/usr/X11/include/freetype2
> -I/usr/X11/include  " "FT2_LIB=-Wl,-framework,CoreServices
> -Wl,-framework,ApplicationServices -L/usr/X11/lib -lfreetype -lz  "
> "ALT_PARALLEL_COMPILE_JOBS=2" "HOTSPOT_BUILD_JOBS=2" "JAVAC="
> "RHINO_JAR=/Users/eric/java-libs/js-engine.jar" "JAR_KNOWS_ATFILE=1"
> "JAR_KNOWS_J_OPTIONS=1" "JAR_ACCEPTS_STDIN_LIST="    \
>       -C openjdk-ecj/control/make \
>
> ../../jdk/make/common/shared/Defs.gmk:157: "WARNING: Value of ARCH cannot be
> empty, will use ''"
> ../../jdk/make/common/shared/Defs.gmk:157: "WARNING: Value of
> ARCH_DATA_MODEL cannot be empty, will use ''"
> ../../jdk/make/common/shared/Defs.gmk:157: "WARNING: Value of PLATFORM
> cannot be empty, will use ''"
> ../../jdk/make/common/shared/Defs.gmk:330:
> ../../jdk/make/common/shared/Defs-.gmk: No such file or directory
> ../../jdk/make/common/shared/Compiler.gmk:46:
> ../../jdk/make/common/shared/Compiler-.gmk: No such file or directory
> make[1]: *** No rule to make target
> `../../jdk/make/common/shared/Compiler-.gmk'.  Stop.
> make: *** [stamps/icedtea-ecj.stamp] Error 2
>
>
>
>
>

As I think we've said, there's no BSD support in IcedTea6.  So unless
you fancy doing another port, this ain't gonna work.  You need to use
7 with the BSD tree for now.
-- 
Andrew :-)

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


From mvfranz at gmail.com  Fri Jan  9 15:47:20 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Fri, 9 Jan 2009 18:47:20 -0500
Subject: Icedtea 7 make patch problem
In-Reply-To: <860cb0120901091010h20d5a9cy133bc3e3744df4f2@mail.gmail.com>
References: <860cb0120901091010h20d5a9cy133bc3e3744df4f2@mail.gmail.com>
Message-ID: <fee4d890901091547x5c12b9c0qd0ac91b5626c18a3@mail.gmail.com>

Eric,

Here is the start of my thread on compiling IcedTea 7 on OS X (intel).

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-December/004365.html

I basically removed all the patches that failed.  I looked at them later in
more detail and most of them are linux specific and probably don't apply for
OS X (bsd).

I am currently trying to use Cacao to bootstrap the build.  Once I can get
the build to work with Cacao, I hope to revisit the patches to see what
needs to be done to integrate bsd into icedtea 7 properly.

Michael

On Fri, Jan 9, 2009 at 1:10 PM, Eric Richardson <ekrichardson at gmail.com>wrote:

> Hello,
>
> I am on PowerPC MacOSX and got much further than yesterday. If there is
> other info needed I can post it tonight.
>
> Checking patches/hotspot/original/icedtea-version.patch
> Applying patches/hotspot/original/icedtea-version.patch
> patching file openjdk/hotspot/make/linux/makefiles/vm.make
> patching file openjdk/hotspot/src/share/vm/utilities/vmError.cpp
> Hunk #1 succeeded at 170 (offset 5 lines).
> Hunk #2 succeeded at 347 (offset 7 lines).
> Checking patches/icedtea-copy-plugs.patch
> 1 out of 3 hunks FAILED -- saving rejects to file
> openjdk/jdk/make/common/internal/BinaryPlugs.gmk.rej
> ERROR patch patches/icedtea-copy-plugs.patch FAILED!
> WARNING make clean-patch before retrying a fix
> make: *** [stamps/patch.stamp] Error 2
>
> Thanks for any ideas,
> Eric
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090109/905691f1/attachment.html 

From mvfranz at gmail.com  Fri Jan  9 15:51:14 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Fri, 9 Jan 2009 18:51:14 -0500
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <1231062689.28600.2.camel@localhost.localdomain>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
Message-ID: <fee4d890901091551p662a9ed8g227a491252d828e3@mail.gmail.com>

Christian,

I have had some success using Cacao.  The instructions you pointed me too
seem out of date and seem be part of some other discussion (I feel like I am
starting in the middle of something when I read them).

the --with-cacao is not a valid options, but --enable-cacao is (I am using
icedtea7).

I will spend some more time trying to figure out what is possible, and
hopefully be able to build with cacao.

Michael

On Sun, Jan 4, 2009 at 4:51 AM, Christian Thalinger <
christian.thalinger at gmail.com> wrote:

> On Sat, 2009-01-03 at 22:04 +0000, Andrew Haley wrote:
> > Michael Franz wrote:
> >
> > > On Sat, Jan 3, 2009 at 4:05 PM, Andrew Haley <aph at redhat.com> wrote:
> > >
> > >> Andrew Haley wrote:
> > >>> Michael Franz wrote:
> > >>>> I have created the following patches that integrate shark build into
> the
> > >>>> bsd-port repo.  I have not been able to get it to compile, but
> wanted
> > >> these
> > >>>> out there in case they are wrong and causing my problem.
> > >>>>
> > >>>> I am currently stuck on this error:
> > >>> Shark on x86 isn't really ready yet.  I've been debugging it and it's
> > >>> starting to look OK, but it's not stable.
> > >> Actually, I've been working on x86_64.  AFAIAA *nobody* has worked on
> > >> x86.  To be honest, I don't really know why you'd want to: the x86
> > >> Hotspot JIT is very good.
> >
> > > I am not necessarily interested in the using zero/shark on intel (32 or
> > > 64).  I am interested int getting zero/shark integrated into the bsd
> port
> > > for other architectures to use.  Since the bsd-port can only be built
> on
> > > intel (32/64) I figured it would be easier to integrate with a working
> build
> > > than trying to do it on ppc which cannot build icedtea (no valid
> bootstrap
> > > jdk).
> >
> > You might be OK with zero on x86 BSD, but almost certainly not with
> shark.
> > I presume the problem with ppc on BSD is that gcj doesn't work there
> either.
>
> Michael, you can use CACAO or JamVM to bootstrap IcedTea.  For some
> instructions see:
>
> http://c1.complang.tuwien.ac.at/cacaowiki/IcedTea
>
> - Christian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090109/75ba08c9/attachment.html 

From christian.thalinger at gmail.com  Sat Jan 10 01:45:45 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Sat, 10 Jan 2009 10:45:45 +0100
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <fee4d890901091551p662a9ed8g227a491252d828e3@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<fee4d890901020928j3d2d3f5eubb74d7713898deae@mail.gmail.com>
	<17c6771e0901021054t91d0efbg325fc5fca068ef3d@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
	<fee4d890901091551p662a9ed8g227a491252d828e3@mail.gmail.com>
Message-ID: <1231580745.26055.4.camel@localhost.localdomain>

On Fri, 2009-01-09 at 18:51 -0500, Michael Franz wrote:
> Christian,
> 
> I have had some success using Cacao.  The instructions you pointed me
> too seem out of date and seem be part of some other discussion (I feel
> like I am starting in the middle of something when I read them).

Starting in the middle?  Well, the instructions for GNU Classpath are
missing.  Anything else?

> 
> the --with-cacao is not a valid options, but --enable-cacao is (I am
> using icedtea7).

You're right.  Andrew changed that.  I'll update the wiki.

> 
> I will spend some more time trying to figure out what is possible, and
> hopefully be able to build with cacao.

- Christian



From christian.thalinger at gmail.com  Sat Jan 10 01:50:22 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Sat, 10 Jan 2009 10:50:22 +0100
Subject: Problem Compiling Java
In-Reply-To: <860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
	<860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>
Message-ID: <1231581022.26055.7.camel@localhost.localdomain>

On Fri, 2009-01-09 at 10:13 -0800, Eric Richardson wrote:
> Michael,
> 
> This fixed the compile problem. I still get this error but it passes
> by it.
> 
> incorrect classpath:
> hotspot-tools/com/sun/codemodel/internal/ClassType.java

AFAIK this happens because of using:

-bootclasspath ''

in the Makefile.  There seems to be some escape problem.  I once wanted
to fix it but... Mark said something about the fix not being properly...
or something like that... I can't remember.

- Christian



From mvfranz at gmail.com  Sat Jan 10 12:03:57 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sat, 10 Jan 2009 15:03:57 -0500
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <1231580745.26055.4.camel@localhost.localdomain>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
	<fee4d890901091551p662a9ed8g227a491252d828e3@mail.gmail.com>
	<1231580745.26055.4.camel@localhost.localdomain>
Message-ID: <fee4d890901101203kc1f653dl24cf290434aaeefe@mail.gmail.com>

On Sat, Jan 10, 2009 at 4:45 AM, Christian Thalinger <
christian.thalinger at gmail.com> wrote:

> On Fri, 2009-01-09 at 18:51 -0500, Michael Franz wrote:
> > Christian,
> >
> > I have had some success using Cacao.  The instructions you pointed me
> > too seem out of date and seem be part of some other discussion (I feel
> > like I am starting in the middle of something when I read them).
>
> Starting in the middle?  Well, the instructions for GNU Classpath are
> missing.  Anything else?


Perhaps I don't understand what this process is suppose to accomplish.  I
thought it was to allow building of icedtea/opendjk using classpath/cacao
(instead of apple's jdk).  So, I have classpath installed and configured to
use cacaovm, but during the icedtea build process it downloads cacao and
tries to build it.  The build fails since there is linux specific code in:
cacao/cacao-0.99.3/src/native/vm/openjdk/jvm.c
jvm.c:3719:3: error: #error not implemented for this OS

I don't know why this did not happen when I built it manually.

So, does this mean that it is trying to build cacao instead of the openjdk
interpreter?

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090110/92f236af/attachment.html 

From mvfranz at gmail.com  Sat Jan 10 12:56:16 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sat, 10 Jan 2009 15:56:16 -0500
Subject: Disable ALSA for Non-Linux builds with configure patch
Message-ID: <fee4d890901101256k3bd4b377x54e1795fe8438cb8@mail.gmail.com>

Hi,

I put together a patch that makes my life easier when trying to compile
IcedTea7 on OS X (should work for all platforms that do not have ALSA).
This adds the --disable-alsa configure switch.  Please comment.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090110/2d3d311c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.ac.patch
Type: application/octet-stream
Size: 1385 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090110/2d3d311c/attachment.obj 

From gnu_andrew at member.fsf.org  Sat Jan 10 16:52:52 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 11 Jan 2009 00:52:52 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <1231580745.26055.4.camel@localhost.localdomain>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<fee4d890901022226y1bdffc1fvb20cede1e3b3ecec@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
	<fee4d890901091551p662a9ed8g227a491252d828e3@mail.gmail.com>
	<1231580745.26055.4.camel@localhost.localdomain>
Message-ID: <17c6771e0901101652s1af2a92mad9caa2c55262dc3@mail.gmail.com>

2009/1/10 Christian Thalinger <christian.thalinger at gmail.com>:
> On Fri, 2009-01-09 at 18:51 -0500, Michael Franz wrote:
>> Christian,
>>
>> I have had some success using Cacao.  The instructions you pointed me
>> too seem out of date and seem be part of some other discussion (I feel
>> like I am starting in the middle of something when I read them).
>
> Starting in the middle?  Well, the instructions for GNU Classpath are
> missing.  Anything else?
>
>>
>> the --with-cacao is not a valid options, but --enable-cacao is (I am
>> using icedtea7).
>
> You're right.  Andrew changed that.  I'll update the wiki.
>
>>
>> I will spend some more time trying to figure out what is possible, and
>> hopefully be able to build with cacao.
>
> - Christian
>
>
>

Yes I changed it because the convention is that --enable-x turns on
and off build options (--disable-x is equivalent to --enable-x=no)
while --with-x is used for build dependencies and can also take a
value such as --with-x=y.  The cacao option was simply a switch to
flick on the CACAO/OpenJDK option and wouldn't handle something like
--with-cacao=y.  We should merge --with-icedtea/--with-icedtea-home
and --with-openjdk/--with-openjdk-home into one for similar reasons.
-- 
Andrew :-)

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


From gnu_andrew at member.fsf.org  Sat Jan 10 16:56:21 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 11 Jan 2009 00:56:21 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <fee4d890901101203kc1f653dl24cf290434aaeefe@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<fee4d890901031136i47c8c25eoa29c43bf58133813@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
	<fee4d890901091551p662a9ed8g227a491252d828e3@mail.gmail.com>
	<1231580745.26055.4.camel@localhost.localdomain>
	<fee4d890901101203kc1f653dl24cf290434aaeefe@mail.gmail.com>
Message-ID: <17c6771e0901101656k7ef4b67eo1613f1ab4d68cad4@mail.gmail.com>

2009/1/10 Michael Franz <mvfranz at gmail.com>:
>
>
> On Sat, Jan 10, 2009 at 4:45 AM, Christian Thalinger
> <christian.thalinger at gmail.com> wrote:
>>
>> On Fri, 2009-01-09 at 18:51 -0500, Michael Franz wrote:
>> > Christian,
>> >
>> > I have had some success using Cacao.  The instructions you pointed me
>> > too seem out of date and seem be part of some other discussion (I feel
>> > like I am starting in the middle of something when I read them).
>>
>> Starting in the middle?  Well, the instructions for GNU Classpath are
>> missing.  Anything else?
>
>
> Perhaps I don't understand what this process is suppose to accomplish.  I
> thought it was to allow building of icedtea/opendjk using classpath/cacao
> (instead of apple's jdk).  So, I have classpath installed and configured to
> use cacaovm, but during the icedtea build process it downloads cacao and
> tries to build it.  The build fails since there is linux specific code in:
> cacao/cacao-0.99.3/src/native/vm/openjdk/jvm.c
> jvm.c:3719:3: error: #error not implemented for this OS
>
> I don't know why this did not happen when I built it manually.
>
> So, does this mean that it is trying to build cacao instead of the openjdk
> interpreter?
>
> Michael
>
>
>
>


I think you ran into exactly the issue that renaming the option
--enable-cacao was aiming at.  --enable-cacao (still --with-cacao in
IcedTea6 AFAIK) turns on the build of CACAO+OpenJDK class library as
opposed to HotSpot+OpenJDK class library.  The default build is set up
for a GNU Classpath JDK as a build option.  You should have a JDK-like
tree around CACAO+Classpath with jre/lib/rt.jar symlinked to
Classpath's glibj.zip and bin/java symlinked to cacao.  I think cacao
has an option to build such a structure in its configure options.
Then you point the build to it using --with-gcj-home.  For the time
being, you also need to point IcedTea7 to the class library explicitly
(--with-libgcj-jar=$JDK_HOME/jre/lib/rt.jar) but this will be
defaulted on the next IcedTea6->7 merge.
-- 
Andrew :-)

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


From ekrichardson at gmail.com  Sat Jan 10 17:24:06 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Sat, 10 Jan 2009 17:24:06 -0800
Subject: Icedtea 7 make patch problem
In-Reply-To: <fee4d890901091547x5c12b9c0qd0ac91b5626c18a3@mail.gmail.com>
References: <860cb0120901091010h20d5a9cy133bc3e3744df4f2@mail.gmail.com>
	<fee4d890901091547x5c12b9c0qd0ac91b5626c18a3@mail.gmail.com>
Message-ID: <860cb0120901101724u62cd7c41l998b216d4b166afa@mail.gmail.com>

Michael,

I will use the info in this thread to help me out.

Eric

On Fri, Jan 9, 2009 at 3:47 PM, Michael Franz <mvfranz at gmail.com> wrote:

> Eric,
>
> Here is the start of my thread on compiling IcedTea 7 on OS X (intel).
>
>
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2008-December/004365.html
>
> I basically removed all the patches that failed.  I looked at them later in
> more detail and most of them are linux specific and probably don't apply for
> OS X (bsd).
>
> I am currently trying to use Cacao to bootstrap the build.  Once I can get
> the build to work with Cacao, I hope to revisit the patches to see what
> needs to be done to integrate bsd into icedtea 7 properly.
>
> Michael
>
>
> On Fri, Jan 9, 2009 at 1:10 PM, Eric Richardson <ekrichardson at gmail.com>wrote:
>
>> Hello,
>>
>> I am on PowerPC MacOSX and got much further than yesterday. If there is
>> other info needed I can post it tonight.
>>
>> Checking patches/hotspot/original/icedtea-version.patch
>> Applying patches/hotspot/original/icedtea-version.patch
>> patching file openjdk/hotspot/make/linux/makefiles/vm.make
>> patching file openjdk/hotspot/src/share/vm/utilities/vmError.cpp
>> Hunk #1 succeeded at 170 (offset 5 lines).
>> Hunk #2 succeeded at 347 (offset 7 lines).
>> Checking patches/icedtea-copy-plugs.patch
>> 1 out of 3 hunks FAILED -- saving rejects to file
>> openjdk/jdk/make/common/internal/BinaryPlugs.gmk.rej
>> ERROR patch patches/icedtea-copy-plugs.patch FAILED!
>> WARNING make clean-patch before retrying a fix
>> make: *** [stamps/patch.stamp] Error 2
>>
>> Thanks for any ideas,
>> Eric
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090110/f7296259/attachment.html 

From ekrichardson at gmail.com  Sat Jan 10 18:32:19 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Sat, 10 Jan 2009 18:32:19 -0800
Subject: Disable ALSA for Non-Linux builds with configure patch
In-Reply-To: <fee4d890901101256k3bd4b377x54e1795fe8438cb8@mail.gmail.com>
References: <fee4d890901101256k3bd4b377x54e1795fe8438cb8@mail.gmail.com>
Message-ID: <860cb0120901101832i4223cf89ue68024e9305dd87@mail.gmail.com>

Hi Michael,

I applied this patch to a clean version of configure.ac and it works great.

checking whether to include ALSA... no

Eric

On Sat, Jan 10, 2009 at 12:56 PM, Michael Franz <mvfranz at gmail.com> wrote:

> Hi,
>
> I put together a patch that makes my life easier when trying to compile
> IcedTea7 on OS X (should work for all platforms that do not have ALSA).
> This adds the --disable-alsa configure switch.  Please comment.
>
> Michael
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090110/68aadddb/attachment.html 

From gnu_andrew at member.fsf.org  Sat Jan 10 19:16:21 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 11 Jan 2009 03:16:21 +0000
Subject: Disable ALSA for Non-Linux builds with configure patch
In-Reply-To: <860cb0120901101832i4223cf89ue68024e9305dd87@mail.gmail.com>
References: <fee4d890901101256k3bd4b377x54e1795fe8438cb8@mail.gmail.com>
	<860cb0120901101832i4223cf89ue68024e9305dd87@mail.gmail.com>
Message-ID: <17c6771e0901101916g5ebbf604k6d77f169d839aa03@mail.gmail.com>

2009/1/11 Eric Richardson <ekrichardson at gmail.com>:
> Hi Michael,
>
> I applied this patch to a clean version of configure.ac and it works great.
>
> checking whether to include ALSA... no
>
> Eric
>
> On Sat, Jan 10, 2009 at 12:56 PM, Michael Franz <mvfranz at gmail.com> wrote:
>>
>> Hi,
>>
>> I put together a patch that makes my life easier when trying to compile
>> IcedTea7 on OS X (should work for all platforms that do not have ALSA).
>> This adds the --disable-alsa configure switch.  Please comment.
>>
>> Michael
>>
>>
>
>

The ALSA check is already disabled for non-GNU/Linux systems in
current IcedTea6.
-- 
Andrew :-)

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


From mvfranz at gmail.com  Sat Jan 10 21:17:47 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sun, 11 Jan 2009 00:17:47 -0500
Subject: Disable ALSA for Non-Linux builds with configure patch
In-Reply-To: <17c6771e0901101916g5ebbf604k6d77f169d839aa03@mail.gmail.com>
References: <fee4d890901101256k3bd4b377x54e1795fe8438cb8@mail.gmail.com>
	<860cb0120901101832i4223cf89ue68024e9305dd87@mail.gmail.com>
	<17c6771e0901101916g5ebbf604k6d77f169d839aa03@mail.gmail.com>
Message-ID: <fee4d890901102117j1bfd142aue70dab30cc95c58c@mail.gmail.com>

When is the next merge?



On 1/10/09, Andrew John Hughes <gnu_andrew at member.fsf.org> wrote:
> 2009/1/11 Eric Richardson <ekrichardson at gmail.com>:
>> Hi Michael,
>>
>> I applied this patch to a clean version of configure.ac and it works
>> great.
>>
>> checking whether to include ALSA... no
>>
>> Eric
>>
>> On Sat, Jan 10, 2009 at 12:56 PM, Michael Franz <mvfranz at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I put together a patch that makes my life easier when trying to compile
>>> IcedTea7 on OS X (should work for all platforms that do not have ALSA).
>>> This adds the --disable-alsa configure switch.  Please comment.
>>>
>>> Michael
>>>
>>>
>>
>>
>
> The ALSA check is already disabled for non-GNU/Linux systems in
> current IcedTea6.
> --
> Andrew :-)
>
> 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
>

-- 
Sent from Gmail for mobile | mobile.google.com


From mark at klomp.org  Sun Jan 11 04:28:52 2009
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 11 Jan 2009 13:28:52 +0100
Subject: Problem Compiling Java
In-Reply-To: <1231581022.26055.7.camel@localhost.localdomain>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
	<860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>
	<1231581022.26055.7.camel@localhost.localdomain>
Message-ID: <1231676932.6745.4.camel@localhost.localdomain>

Hi Christian,

On Sat, 2009-01-10 at 10:50 +0100, Christian Thalinger wrote:
> On Fri, 2009-01-09 at 10:13 -0800, Eric Richardson wrote:
> > incorrect classpath:
> > hotspot-tools/com/sun/codemodel/internal/ClassType.java
> 
> AFAIK this happens because of using:
> 
> -bootclasspath ''
> 
> in the Makefile.  There seems to be some escape problem.  I once wanted
> to fix it but... Mark said something about the fix not being properly...
> or something like that... I can't remember.

I cannot remember what this was precisely. Could you post a pointer to
your fix? I am sure we can work out something that works for all
compilers.

Thanks,

Mark



From christian.thalinger at gmail.com  Sun Jan 11 04:52:23 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Sun, 11 Jan 2009 13:52:23 +0100
Subject: Problem Compiling Java
In-Reply-To: <1231676932.6745.4.camel@localhost.localdomain>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
	<860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>
	<1231581022.26055.7.camel@localhost.localdomain>
	<1231676932.6745.4.camel@localhost.localdomain>
Message-ID: <1231678343.18329.0.camel@localhost.localdomain>

On Sun, 2009-01-11 at 13:28 +0100, Mark Wielaard wrote:
> Hi Christian,
> 
> On Sat, 2009-01-10 at 10:50 +0100, Christian Thalinger wrote:
> > On Fri, 2009-01-09 at 10:13 -0800, Eric Richardson wrote:
> > > incorrect classpath:
> > > hotspot-tools/com/sun/codemodel/internal/ClassType.java
> > 
> > AFAIK this happens because of using:
> > 
> > -bootclasspath ''
> > 
> > in the Makefile.  There seems to be some escape problem.  I once wanted
> > to fix it but... Mark said something about the fix not being properly...
> > or something like that... I can't remember.
> 
> I cannot remember what this was precisely. Could you post a pointer to
> your fix? I am sure we can work out something that works for all
> compilers.

I simply escaped them once:

-bootclasspath \'\'

At least that worked on my box.

- Christian



From mark at klomp.org  Sun Jan 11 05:10:58 2009
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 11 Jan 2009 14:10:58 +0100
Subject: Problem Compiling Java
In-Reply-To: <1231678343.18329.0.camel@localhost.localdomain>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
	<860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>
	<1231581022.26055.7.camel@localhost.localdomain>
	<1231676932.6745.4.camel@localhost.localdomain>
	<1231678343.18329.0.camel@localhost.localdomain>
Message-ID: <1231679458.6745.11.camel@localhost.localdomain>

Hi Christian,

On Sun, 2009-01-11 at 13:52 +0100, Christian Thalinger wrote:
> I simply escaped them once:
> 
> -bootclasspath \'\'
> 
> At least that worked on my box.

You mean like in the attached patch?
That seems correct to me because in all those cases it is a shell
snippet inside the Makefile. If I said that was wrong in the past, I
cannot remember why I thought so. Running a full bootstrap now to double
check. Will check it in if that passes. OK?

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.am.escape.patch
Type: text/x-patch
Size: 1965 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090111/7756fb20/attachment.bin 

From christian.thalinger at gmail.com  Sun Jan 11 05:16:56 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Sun, 11 Jan 2009 14:16:56 +0100
Subject: Problem Compiling Java
In-Reply-To: <1231679458.6745.11.camel@localhost.localdomain>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
	<860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>
	<1231581022.26055.7.camel@localhost.localdomain>
	<1231676932.6745.4.camel@localhost.localdomain>
	<1231678343.18329.0.camel@localhost.localdomain>
	<1231679458.6745.11.camel@localhost.localdomain>
Message-ID: <1231679816.18329.2.camel@localhost.localdomain>

On Sun, 2009-01-11 at 14:10 +0100, Mark Wielaard wrote:
> Hi Christian,
> 
> On Sun, 2009-01-11 at 13:52 +0100, Christian Thalinger wrote:
> > I simply escaped them once:
> > 
> > -bootclasspath \'\'
> > 
> > At least that worked on my box.
> 
> You mean like in the attached patch?
> That seems correct to me because in all those cases it is a shell
> snippet inside the Makefile. If I said that was wrong in the past, I
> cannot remember why I thought so. Running a full bootstrap now to double
> check. Will check it in if that passes. OK?

Exactly like the attached patch.  Please commit if it's OK.

- Christian



From bugzilla-daemon at icedtea.classpath.org  Sun Jan 11 07:10:00 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sun, 11 Jan 2009 15:10:00 +0000
Subject: [Bug 281] New: web100 applet fails to display buttons
Message-ID: <E1LM1wu-0001CV-5f@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=281

           Summary: web100 applet fails to display buttons
           Product: IcedTea
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: IcedTea
        AssignedTo: unassigned at icedtea.classpath.org
        ReportedBy: vijay at online.nl


http://ndt.switch.ch/

- Starts the applet
- Displays the applet (click START to begin)
- Briefly displays buttons
- Buttons disappear
- No events generated when clicking where the buttons previously appeared

Fedora 10, x86_64, java-1.6.0-openjdk-plugin.x86_64


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Sun Jan 11 07:48:00 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sun, 11 Jan 2009 15:48:00 +0000
Subject: [Bug 281] web100 applet fails to display buttons
Message-ID: <E1LM2Xg-0001ET-V5@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=281


langel at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




------- Comment #1 from langel at redhat.com  2009-01-11 15:48 -------
works fine for me on x86_64, with
java-1.6.0-openjdk-plugin-1.6.0.0-8.b14.fc11.x86_64


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Sun Jan 11 09:13:18 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sun, 11 Jan 2009 17:13:18 +0000
Subject: [Bug 281] web100 applet fails to display buttons
Message-ID: <E1LM3sE-0001Jb-4D@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=281


vijay at online.nl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |




------- Comment #2 from vijay at online.nl  2009-01-11 17:13 -------
Problem persists with f11 plugin. 

- Upgraded to:
java-1.6.0-openjdk-1:1.6.0.0-8.b14.fc11.x86_64
java-1.6.0-openjdk-plugin-1:1.6.0.0-8.b14.fc11.x86_64

- Firefox (3.05, x86_64) reports:
IcedTea Web Browser Plugin

    File name: IcedTeaPlugin.so
    The IcedTea Web Browser Plugin 1.4 (fedora-8.b14.fc11-x86_64) executes Java
applets.
...

- http://ndt.switch.ch/
Buttons appear briefly (less than 1 second) and then disappear. Can't generate
(button) events by clicking where the buttons previously appeared.


I've now tried this on two machines.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From gnu_andrew at member.fsf.org  Sun Jan 11 09:19:12 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 11 Jan 2009 17:19:12 +0000
Subject: Problem Compiling Java
In-Reply-To: <1231679816.18329.2.camel@localhost.localdomain>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
	<860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>
	<1231581022.26055.7.camel@localhost.localdomain>
	<1231676932.6745.4.camel@localhost.localdomain>
	<1231678343.18329.0.camel@localhost.localdomain>
	<1231679458.6745.11.camel@localhost.localdomain>
	<1231679816.18329.2.camel@localhost.localdomain>
Message-ID: <17c6771e0901110919q349bbd66y1466e60ee568fb10@mail.gmail.com>

2009/1/11 Christian Thalinger <christian.thalinger at gmail.com>:
> On Sun, 2009-01-11 at 14:10 +0100, Mark Wielaard wrote:
>> Hi Christian,
>>
>> On Sun, 2009-01-11 at 13:52 +0100, Christian Thalinger wrote:
>> > I simply escaped them once:
>> >
>> > -bootclasspath \'\'
>> >
>> > At least that worked on my box.
>>
>> You mean like in the attached patch?
>> That seems correct to me because in all those cases it is a shell
>> snippet inside the Makefile. If I said that was wrong in the past, I
>> cannot remember why I thought so. Running a full bootstrap now to double
>> check. Will check it in if that passes. OK?
>
> Exactly like the attached patch.  Please commit if it's OK.
>
> - Christian
>
>
>

FWIW we use a Perl version in IcedTea7 to get round this issue.
-- 
Andrew :-)

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


From christian.thalinger at gmail.com  Sun Jan 11 09:38:10 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Sun, 11 Jan 2009 18:38:10 +0100
Subject: Problem Compiling Java
In-Reply-To: <17c6771e0901110919q349bbd66y1466e60ee568fb10@mail.gmail.com>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
	<860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>
	<1231581022.26055.7.camel@localhost.localdomain>
	<1231676932.6745.4.camel@localhost.localdomain>
	<1231678343.18329.0.camel@localhost.localdomain>
	<1231679458.6745.11.camel@localhost.localdomain>
	<1231679816.18329.2.camel@localhost.localdomain>
	<17c6771e0901110919q349bbd66y1466e60ee568fb10@mail.gmail.com>
Message-ID: <1231695490.18329.12.camel@localhost.localdomain>

On Sun, 2009-01-11 at 17:19 +0000, Andrew John Hughes wrote:
> FWIW we use a Perl version in IcedTea7 to get round this issue.

Ohh, great!  Back-port it!

- Christian



From bugzilla-daemon at icedtea.classpath.org  Sun Jan 11 09:54:59 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sun, 11 Jan 2009 17:54:59 +0000
Subject: [Bug 281] web100 applet fails to display buttons
Message-ID: <E1LM4WZ-0001MA-VR@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=281





------- Comment #3 from vijay at online.nl  2009-01-11 17:54 -------
This bug seems to be partially related to my/the bug in <a
href="http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=263">263</a>.

Both bugs share the commonality in that the event processing appears to cease
after less than 1 second after loading the applet.

However with the web100 applet, I'm not experiencing the backwards text
situation going on in bug 263.

I do see continuous snowing in this applet: http://www.v-workshops.com/java/
(until the snow pile has filled up the entire applet window)


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From mark at klomp.org  Sun Jan 11 09:56:56 2009
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 11 Jan 2009 17:56:56 +0000
Subject: changeset in /hg/icedtea6: * Makefile.am: Escape single quotes i...
Message-ID: <hg.bce8d56dfa03.1231696616.2873452341184383832@icedtea.classpath.org>

changeset bce8d56dfa03 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=bce8d56dfa03
description:
	* Makefile.am: Escape single quotes in empty bootclasspath.

diffstat:

2 files changed, 10 insertions(+), 6 deletions(-)
ChangeLog   |    4 ++++
Makefile.am |   12 ++++++------

diffs (62 lines):

diff -r 508839ea3465 -r bce8d56dfa03 ChangeLog
--- a/ChangeLog	Fri Jan 09 11:53:07 2009 -0500
+++ b/ChangeLog	Sun Jan 11 18:56:44 2009 +0100
@@ -1,3 +1,7 @@ 2009-01-09  Omair Majid  <omajid at redhat.
+2009-01-11  Mark Wielaard  <mark at klomp.org>
+
+	* Makefile.am: Escape single quotes in empty bootclasspath.
+
 2009-01-09  Omair Majid  <omajid at redhat.com>
 
 	* patches/icedtea-awt-window-size.patch: New file. Fix X11 window size
diff -r 508839ea3465 -r bce8d56dfa03 Makefile.am
--- a/Makefile.am	Fri Jan 09 11:53:07 2009 -0500
+++ b/Makefile.am	Sun Jan 11 18:56:44 2009 +0100
@@ -1428,14 +1428,14 @@ stamps/hotspot-tools-class-files.stamp: 
             -source 1.5 \
             -sourcepath \
 	      'hotspot-tools:$(OPENJDK_SOURCEPATH_DIRS):$(ABS_SOURCE_DIRS)' \
-            -bootclasspath '' @$< ; \
+            -bootclasspath \'\' @$< ; \
 	else \
 	  $(ICEDTEA_BOOT_DIR)/bin/javac $(MEMORY_LIMIT) -g \
 	    -d lib/hotspot-tools \
 	    -source 1.5 \
 	    -sourcepath \
 	      'hotspot-tools:$(OPENJDK_SOURCEPATH_DIRS):$(ABS_SOURCE_DIRS)' \
-	    -bootclasspath '' @$< ; \
+	    -bootclasspath \'\' @$< ; \
 	fi
 	mkdir -p stamps
 	touch stamps/hotspot-tools-class-files.stamp
@@ -1480,13 +1480,13 @@ stamps/rt-class-files.stamp: rt-source-f
 	    -source 1.5 \
 	    -sourcepath \
 	      '$(OPENJDK_SOURCEPATH_DIRS):$(abs_top_builddir)/generated' \
-	    -bootclasspath '' @$< ; \
+	    -bootclasspath \'\' @$< ; \
 	else \
 	  $(ICEDTEA_BOOT_DIR)/bin/javac $(MEMORY_LIMIT) -g -d lib/rt \
             -source 1.5 \
             -sourcepath \
 	      '$(OPENJDK_SOURCEPATH_DIRS):$(abs_top_builddir)/generated' \
-            -bootclasspath '' @$< ; \
+            -bootclasspath \'\' @$< ; \
 	fi
 	cp -r $(abs_top_srcdir)/rt/net/sourceforge/jnlp/resources \
 	  lib/rt/net/sourceforge/jnlp/
@@ -1527,12 +1527,12 @@ stamps/extra-class-files.stamp: extra-so
 	  $(JAVAC) $(MEMORY_LIMIT) -g -d extra-lib \
 	    -source 1.5 \
 	    -sourcepath extra -cp bootstrap/jdk1.7.0/jre/lib/rt-closed.jar \
-	    -bootclasspath '' @extra-source-files.txt ; \
+	    -bootclasspath \'\' @extra-source-files.txt ; \
 	else \
 	  $(ICEDTEA_BOOT_DIR)/bin/javac $(MEMORY_LIMIT) -g -d extra-lib \
             -source 1.5 \
             -sourcepath extra -cp bootstrap/jdk1.7.0/jre/lib/rt-closed.jar \
-            -bootclasspath '' @extra-source-files.txt ; \
+            -bootclasspath \'\' @extra-source-files.txt ; \
 	fi
 	cp -r $(abs_top_srcdir)/extra/net/sourceforge/jnlp/about/resources \
 	  extra-lib/net/sourceforge/jnlp/about


From mark at klomp.org  Sun Jan 11 10:23:00 2009
From: mark at klomp.org (Mark Wielaard)
Date: Sun, 11 Jan 2009 19:23:00 +0100
Subject: Problem Compiling Java
In-Reply-To: <17c6771e0901110919q349bbd66y1466e60ee568fb10@mail.gmail.com>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>
	<1231406551.16494.32.camel@localhost.localdomain>
	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>
	<860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>
	<1231581022.26055.7.camel@localhost.localdomain>
	<1231676932.6745.4.camel@localhost.localdomain>
	<1231678343.18329.0.camel@localhost.localdomain>
	<1231679458.6745.11.camel@localhost.localdomain>
	<1231679816.18329.2.camel@localhost.localdomain>
	<17c6771e0901110919q349bbd66y1466e60ee568fb10@mail.gmail.com>
Message-ID: <1231698180.2504.5.camel@localhost.localdomain>

Hi Andrew,

On Sun, 2009-01-11 at 17:19 +0000, Andrew John Hughes wrote:
> 2009/1/11 Christian Thalinger <christian.thalinger at gmail.com>:
> > On Sun, 2009-01-11 at 14:10 +0100, Mark Wielaard wrote:
> >> On Sun, 2009-01-11 at 13:52 +0100, Christian Thalinger wrote:
> >> > I simply escaped them once:
> >> >
> >> > -bootclasspath \'\'
> >> >
> >> > At least that worked on my box.
> >>
> >> You mean like in the attached patch?
> >> That seems correct to me because in all those cases it is a shell
> >> snippet inside the Makefile. If I said that was wrong in the past, I
> >> cannot remember why I thought so. Running a full bootstrap now to double
> >> check. Will check it in if that passes. OK?
> >
> > Exactly like the attached patch.  Please commit if it's OK.
>
> FWIW we use a Perl version in IcedTea7 to get round this issue.

So, it is only once we parse the empty argument in the javac.in script
that it disappears? In that case it would be good to have the
alternative javac.in script backported to icedtea6 indeed. It is a more
general solution that what I checked in (although I don't believe there
is an empty bootclasspath set anywhere else in the build).

Cheers,

Mark



From ekrichardson at gmail.com  Sun Jan 11 19:31:12 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Sun, 11 Jan 2009 19:31:12 -0800
Subject: Power PC Build
In-Reply-To: <fee4d890901111417v79a2c4bch9978c062758d8c97@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<fee4d890901111417v79a2c4bch9978c062758d8c97@mail.gmail.com>
Message-ID: <860cb0120901111931x5dcc73a8k6dbcd09733b6dec7@mail.gmail.com>

Michael,

On Sun, Jan 11, 2009 at 2:17 PM, Michael Franz <mvfranz at gmail.com> wrote:

> Eric,
>
> How is your progress with building on PowerPC?  I have been able to get
> hotspot to compile using Apple's JDK5, but I cannot get the complete JDK to
> build.
>
> Michael


I'm using this to configure.

export LDFLAGS='-L/opt/local/lib';
./configure --enable-zero=yes --with-project=bsd
--with-gcj-home=/Library/Java/Home
--with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
--with-xalan2-jar=/opt/local/share/java/xalan.jar
--with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
--with-xerces2-jar=/opt/local/share/java/xercesImpl.jar
--with-rhino=/Users/eric/java-libs/js-engine.jar --disable-liveconnect
--with-libgcj-jar=/Library/Java/Home/jre/lib/rt.jar --disable-alsa

So far, I have a couple of patching problems that I ignored.


Checking patches/hotspot/original/icedtea-version.patch
Applying patches/hotspot/original/icedtea-version.patch
patching file openjdk/hotspot/make/linux/makefiles/vm.make
patching file openjdk/hotspot/src/share/vm/utilities/vmError.cpp
Hunk #1 succeeded at 170 (offset 5 lines).
Hunk #2 succeeded at 347 (offset 7 lines).
Checking patches/icedtea-copy-plugs.patch
1 out of 3 hunks FAILED -- saving rejects to file
openjdk/jdk/make/common/internal/BinaryPlugs.gmk.rej
ERROR patch patches/icedtea-copy-plugs.patch FAILED!
WARNING make clean-patch before retrying a fix
make: *** [stamps/patch.stamp] Error 2


Checking patches/ecj/icedtea.patch
1 out of 1 hunk FAILED -- saving rejects to file
openjdk-ecj/corba/make/common/Defs-linux.gmk.rej
1 out of 2 hunks FAILED -- saving rejects to file
openjdk-ecj/jaxp/make/build.xml.rej
1 out of 2 hunks FAILED -- saving rejects to file
openjdk-ecj/jaxws/make/build.xml.rej
1 out of 1 hunk FAILED -- saving rejects to file
openjdk-ecj/jaxws/make/Makefile.rej
ERROR patch patches/ecj/icedtea.patch FAILED!

Then I get a error because the system has a space in it.

jdk/make/common/shared/Defs.gmk:478: "WARNING: Value of OUTPUTDIR contains a
space: './build/bsd-Power Macintosh', check or set ALT_OUTPUTDIR"
jdk/make/common/shared/Defs.gmk:498: "WARNING: Value of ABS_OUTPUTDIR
contains a space: '/Users/eric/java/icedtea/openjdk-ecj/build/bsd-Power
Macintosh', check or set ALT_ABS_OUTPUTDIR"
jdk/make/common/shared/Defs.gmk:505: *** "ERROR: Trouble with the absolute
path for OUTPUTDIR 'Check_ALT_OUTPUTDIR'".  Stop.
make: *** [stamps/icedtea-ecj.stamp] Error 2

So now I use this as the make command.

make ALT_OUTPUTDIR=`pwd`/build/bsd-PowerMacintosh
ALT_CUPS_HEADERS_PATH=/opt/local/include
FREETYPE_HEADERS_PATH=/opt/local/include
ALT_FREETYPE_LIB_PATH=/opt/local/lib

It finds everthing in the configure but when it gets to the build it can't
find cups and freetype - there may be an option in configure but haven't
looked at that yet.
...
checking cups/cups.h usability... yes
checking cups/cups.h presence... yes
checking for cups/cups.h... yes
checking cups/ppd.h usability... yes
checking cups/ppd.h presence... yes
checking for cups/ppd.h... yes
...
checking for FREETYPE2... yes


Finally I get to the ant build and get this error and haven't had a chance
to look at this yet either.

build-bootstrap-javac:
    [javac] Compiling 261 source files to
/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/bootstrap/classes
    [javac]
/Users/eric/java/icedtea/openjdk-ecj/langtools/src/share/classes/com/sun/tools/javac/tree/JCTree.java:79:
interface expected here
    [javac] public abstract class JCTree implements Tree, Cloneable,
DiagnosticPosition {
    [javac]                                         ^
    [javac]
/Users/eric/java/icedtea/openjdk-ecj/langtools/src/share/classes/com/sun/tools/javac/tree/JCTree.java:1926:
cannot find symbol
    [javac] symbol  : class Kind
    [javac] location: class com.sun.tools.javac.tree.JCTree.TypeBoundKind
    [javac]         public Kind getKind() {
    [javac]                ^

Something isn't built obviously. Everybody on the lists has patient and
helpful so I'm sure I'll continue to make progress on the build. I am
interested in the Makefile changes submitted for the bsd port to see if they
will help. Don't know how to try them yet either. New to Mercurial.

I'm glad you are working on the Intel version as the platform should be
virtually identical except for the processor type. compiler flags etc. I
need to use the zero assembly but I guess you wouldn't.

Thanks for asking,

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090111/e769c6e8/attachment.html 

From mvfranz at gmail.com  Sun Jan 11 19:34:32 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sun, 11 Jan 2009 22:34:32 -0500
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <17c6771e0901101656k7ef4b67eo1613f1ab4d68cad4@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
	<fee4d890901091551p662a9ed8g227a491252d828e3@mail.gmail.com>
	<1231580745.26055.4.camel@localhost.localdomain>
	<fee4d890901101203kc1f653dl24cf290434aaeefe@mail.gmail.com>
	<17c6771e0901101656k7ef4b67eo1613f1ab4d68cad4@mail.gmail.com>
Message-ID: <fee4d890901111934s4ad3c9f9gf6be6e07a1679526@mail.gmail.com>

Hi,

Two issues that I have found when trying to compile on a non-linux platfor
are:
1. LINUX_DIR this is defined as linux-$(BUILD_ARCH_DIR).  When building
using the --with-project=bsd it needs to be bsd-$(BUILD_ARCH_DIR)
2. the assumption that shared libraries end in so.
cp openjdk-ecj/build/linux-i586/hotspot/import/jre/lib/i586/server/libjvm.so
\
       openjdk-ecj/build/linux-i586/j2sdk-image/jre/lib/i586/server
On OS X the extension is dylib.

The OpenJDK build determines the correct values for this, but since IcedTea
is a wrapper  around the build process it does not know.  Would adding these
as configure options be the best way to handle this?

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090111/71fd0c83/attachment.html 

From mvfranz at gmail.com  Sun Jan 11 19:52:51 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sun, 11 Jan 2009 22:52:51 -0500
Subject: Power PC Build
In-Reply-To: <860cb0120901111931x5dcc73a8k6dbcd09733b6dec7@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<fee4d890901111417v79a2c4bch9978c062758d8c97@mail.gmail.com>
	<860cb0120901111931x5dcc73a8k6dbcd09733b6dec7@mail.gmail.com>
Message-ID: <fee4d890901111952x1dd113b1p4eefe6762cc95d75@mail.gmail.com>

Eric,

On Sun, Jan 11, 2009 at 10:31 PM, Eric Richardson <ekrichardson at gmail.com>wrote:

> Michael,
>
> On Sun, Jan 11, 2009 at 2:17 PM, Michael Franz <mvfranz at gmail.com> wrote:
>
>> Eric,
>>
>> How is your progress with building on PowerPC?  I have been able to get
>> hotspot to compile using Apple's JDK5, but I cannot get the complete JDK to
>> build.
>>
>> Michael
>
>
> I'm using this to configure.
>
> export LDFLAGS='-L/opt/local/lib';
> ./configure --enable-zero=yes --with-project=bsd
> --with-gcj-home=/Library/Java/Home
> --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
> --with-xalan2-jar=/opt/local/share/java/xalan.jar
> --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
> --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar
> --with-rhino=/Users/eric/java-libs/js-engine.jar --disable-liveconnect
> --with-libgcj-jar=/Library/Java/Home/jre/lib/rt.jar --disable-alsa
>
> So far, I have a couple of patching problems that I ignored.
>
>
> Checking patches/hotspot/original/icedtea-version.patch
> Applying patches/hotspot/original/icedtea-version.patch
> patching file openjdk/hotspot/make/linux/makefiles/vm.make
> patching file openjdk/hotspot/src/share/vm/utilities/vmError.cpp
> Hunk #1 succeeded at 170 (offset 5 lines).
> Hunk #2 succeeded at 347 (offset 7 lines).
> Checking patches/icedtea-copy-plugs.patch
> 1 out of 3 hunks FAILED -- saving rejects to file
> openjdk/jdk/make/common/internal/BinaryPlugs.gmk.rej
> ERROR patch patches/icedtea-copy-plugs.patch FAILED!
> WARNING make clean-patch before retrying a fix
> make: *** [stamps/patch.stamp] Error 2
>

I edit the breaking patches out of the Makefile.  That way, all the ones
that do work get applied.  If you just re-run make after this error, the
rest of the patches are not applied (I think) and that might be the cause of
your compilation errors below.


>
>
> Checking patches/ecj/icedtea.patch
> 1 out of 1 hunk FAILED -- saving rejects to file
> openjdk-ecj/corba/make/common/Defs-linux.gmk.rej
> 1 out of 2 hunks FAILED -- saving rejects to file
> openjdk-ecj/jaxp/make/build.xml.rej
> 1 out of 2 hunks FAILED -- saving rejects to file
> openjdk-ecj/jaxws/make/build.xml.rej
> 1 out of 1 hunk FAILED -- saving rejects to file
> openjdk-ecj/jaxws/make/Makefile.rej
> ERROR patch patches/ecj/icedtea.patch FAILED!
>
> Then I get a error because the system has a space in it.
>
> jdk/make/common/shared/Defs.gmk:478: "WARNING: Value of OUTPUTDIR contains
> a space: './build/bsd-Power Macintosh', check or set ALT_OUTPUTDIR"
> jdk/make/common/shared/Defs.gmk:498: "WARNING: Value of ABS_OUTPUTDIR
> contains a space: '/Users/eric/java/icedtea/openjdk-ecj/build/bsd-Power
> Macintosh', check or set ALT_ABS_OUTPUTDIR"
> jdk/make/common/shared/Defs.gmk:505: *** "ERROR: Trouble with the absolute
> path for OUTPUTDIR 'Check_ALT_OUTPUTDIR'".  Stop.
> make: *** [stamps/icedtea-ecj.stamp] Error 2
>

I would have thought it would be something like bsd-ppc instead of bsd-Power
Macintosh.


>
> So now I use this as the make command.
>
> make ALT_OUTPUTDIR=`pwd`/build/bsd-PowerMacintosh
> ALT_CUPS_HEADERS_PATH=/opt/local/include
> FREETYPE_HEADERS_PATH=/opt/local/include
> ALT_FREETYPE_LIB_PATH=/opt/local/lib
>
> It finds everthing in the configure but when it gets to the build it can't
> find cups and freetype - there may be an option in configure but haven't
> looked at that yet.
> ...
> checking cups/cups.h usability... yes
> checking cups/cups.h presence... yes
> checking for cups/cups.h... yes
> checking cups/ppd.h usability... yes
> checking cups/ppd.h presence... yes
> checking for cups/ppd.h... yes
> ...
> checking for FREETYPE2... yes
>
>
> Finally I get to the ant build and get this error and haven't had a chance
> to look at this yet either.
>
> build-bootstrap-javac:
>     [javac] Compiling 261 source files to
> /Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/bootstrap/classes
>     [javac]
> /Users/eric/java/icedtea/openjdk-ecj/langtools/src/share/classes/com/sun/tools/javac/tree/JCTree.java:79:
> interface expected here
>     [javac] public abstract class JCTree implements Tree, Cloneable,
> DiagnosticPosition {
>     [javac]                                         ^
>     [javac]
> /Users/eric/java/icedtea/openjdk-ecj/langtools/src/share/classes/com/sun/tools/javac/tree/JCTree.java:1926:
> cannot find symbol
>     [javac] symbol  : class Kind
>     [javac] location: class com.sun.tools.javac.tree.JCTree.TypeBoundKind
>     [javac]         public Kind getKind() {
>     [javac]                ^
>
>
> Something isn't built obviously. Everybody on the lists has patient and
> helpful so I'm sure I'll continue to make progress on the build. I am
> interested in the Makefile changes submitted for the bsd port to see if they
> will help. Don't know how to try them yet either. New to Mercurial.
>

Are you using icedtea 6 or 7?  I have been using 7 with the bsd option since
it has all of the bsd changes in it.


>
> I'm glad you are working on the Intel version as the platform should be
> virtually identical except for the processor type. compiler flags etc. I
> need to use the zero assembly but I guess you wouldn't.
>
> Thanks for asking,
>
No problem.  Getting IcedTea on Power Macs would be very good.

>
> Eric
>

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090111/51fdc704/attachment.html 

From matthew.flaschen at gatech.edu  Sun Jan 11 20:08:40 2009
From: matthew.flaschen at gatech.edu (Matthew Flaschen)
Date: Sun, 11 Jan 2009 23:08:40 -0500
Subject: Problem Compiling Java
In-Reply-To: <17c6771e0901110919q349bbd66y1466e60ee568fb10@mail.gmail.com>
References: <860cb0120901072056g5565f34dkab067046af9e90b0@mail.gmail.com>	<1231406551.16494.32.camel@localhost.localdomain>	<fee4d890901080414w4ee3e25fw574fdb68b6af4fbc@mail.gmail.com>	<860cb0120901091013u497f4c9fn57588bef12978f8d@mail.gmail.com>	<1231581022.26055.7.camel@localhost.localdomain>	<1231676932.6745.4.camel@localhost.localdomain>	<1231678343.18329.0.camel@localhost.localdomain>	<1231679458.6745.11.camel@localhost.localdomain>	<1231679816.18329.2.camel@localhost.localdomain>
	<17c6771e0901110919q349bbd66y1466e60ee568fb10@mail.gmail.com>
Message-ID: <496AC248.8060708@gatech.edu>

Andrew John Hughes wrote:
> 2009/1/11 Christian Thalinger <christian.thalinger at gmail.com>:
>> On Sun, 2009-01-11 at 14:10 +0100, Mark Wielaard wrote:
>>> Hi Christian,
>>>
>>> On Sun, 2009-01-11 at 13:52 +0100, Christian Thalinger wrote:
>>>> I simply escaped them once:
>>>>
>>>> -bootclasspath \'\'
>>>>
>>>> At least that worked on my box.
>>> You mean like in the attached patch?
>>> That seems correct to me because in all those cases it is a shell
>>> snippet inside the Makefile. If I said that was wrong in the past, I
>>> cannot remember why I thought so. Running a full bootstrap now to double
>>> check. Will check it in if that passes. OK?
>> Exactly like the attached patch.  Please commit if it's OK.

I get:

if ! test -d /home/matthew/Code/Java/IcedTea/icedtea6/bootstrap/jdk1.6.0 ; \
        then \
          /usr/bin/ecj -nowarn  -g -d lib/rt \
            -source 1.5 \
            -sourcepath \

'openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes:openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/home/matthew/Code/Java/IcedTea/icedtea6/generated'
\
            -bootclasspath \'\' @rt-source-files.txt ; \
        else \

/home/matthew/Code/Java/IcedTea/icedtea6/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/jaxp/src/share/classes:openjdk/corba/src/share/classes:openjdk/jaxws/src/share/classes:/home/matthew/Code/Java/IcedTea/icedtea6/generated'
\
            -bootclasspath \'\' @rt-source-files.txt ; \
        fi
incorrect classpath: ''

But the build hasn't stopped thus far.

Matt Flaschen


From ekrichardson at gmail.com  Sun Jan 11 20:59:44 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Sun, 11 Jan 2009 20:59:44 -0800
Subject: Power PC Build
In-Reply-To: <fee4d890901111952x1dd113b1p4eefe6762cc95d75@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<fee4d890901111417v79a2c4bch9978c062758d8c97@mail.gmail.com>
	<860cb0120901111931x5dcc73a8k6dbcd09733b6dec7@mail.gmail.com>
	<fee4d890901111952x1dd113b1p4eefe6762cc95d75@mail.gmail.com>
Message-ID: <860cb0120901112059s76ff0bet72ee38e3684b17c6@mail.gmail.com>

Michael,

On Sun, Jan 11, 2009 at 7:52 PM, Michael Franz <mvfranz at gmail.com> wrote:

> Eric,
>
> On Sun, Jan 11, 2009 at 10:31 PM, Eric Richardson <ekrichardson at gmail.com>wrote:
>
>> Michael,
>>
>> On Sun, Jan 11, 2009 at 2:17 PM, Michael Franz <mvfranz at gmail.com> wrote:
>>
>>> Eric,
>>>
>>> How is your progress with building on PowerPC?  I have been able to get
>>> hotspot to compile using Apple's JDK5, but I cannot get the complete JDK to
>>> build.
>>>
>>> Michael
>>
>>
>> I'm using this to configure.
>>
>> export LDFLAGS='-L/opt/local/lib';
>> ./configure --enable-zero=yes --with-project=bsd
>> --with-gcj-home=/Library/Java/Home
>> --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
>> --with-xalan2-jar=/opt/local/share/java/xalan.jar
>> --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
>> --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar
>> --with-rhino=/Users/eric/java-libs/js-engine.jar --disable-liveconnect
>> --with-libgcj-jar=/Library/Java/Home/jre/lib/rt.jar --disable-alsa
>>
>> So far, I have a couple of patching problems that I ignored.
>>
>>
>> Checking patches/hotspot/original/icedtea-version.patch
>> Applying patches/hotspot/original/icedtea-version.patch
>> patching file openjdk/hotspot/make/linux/makefiles/vm.make
>> patching file openjdk/hotspot/src/share/vm/utilities/vmError.cpp
>> Hunk #1 succeeded at 170 (offset 5 lines).
>> Hunk #2 succeeded at 347 (offset 7 lines).
>> Checking patches/icedtea-copy-plugs.patch
>> 1 out of 3 hunks FAILED -- saving rejects to file
>> openjdk/jdk/make/common/internal/BinaryPlugs.gmk.rej
>> ERROR patch patches/icedtea-copy-plugs.patch FAILED!
>> WARNING make clean-patch before retrying a fix
>> make: *** [stamps/patch.stamp] Error 2
>>
>
> I edit the breaking patches out of the Makefile.  That way, all the ones
> that do work get applied.  If you just re-run make after this error, the
> rest of the patches are not applied (I think) and that might be the cause of
> your compilation errors below.
>
>
>>
>>
>> Checking patches/ecj/icedtea.patch
>> 1 out of 1 hunk FAILED -- saving rejects to file
>> openjdk-ecj/corba/make/common/Defs-linux.gmk.rej
>> 1 out of 2 hunks FAILED -- saving rejects to file
>> openjdk-ecj/jaxp/make/build.xml.rej
>> 1 out of 2 hunks FAILED -- saving rejects to file
>> openjdk-ecj/jaxws/make/build.xml.rej
>> 1 out of 1 hunk FAILED -- saving rejects to file
>> openjdk-ecj/jaxws/make/Makefile.rej
>> ERROR patch patches/ecj/icedtea.patch FAILED!
>>
>> Then I get a error because the system has a space in it.
>>
>> jdk/make/common/shared/Defs.gmk:478: "WARNING: Value of OUTPUTDIR contains
>> a space: './build/bsd-Power Macintosh', check or set ALT_OUTPUTDIR"
>> jdk/make/common/shared/Defs.gmk:498: "WARNING: Value of ABS_OUTPUTDIR
>> contains a space: '/Users/eric/java/icedtea/openjdk-ecj/build/bsd-Power
>> Macintosh', check or set ALT_ABS_OUTPUTDIR"
>> jdk/make/common/shared/Defs.gmk:505: *** "ERROR: Trouble with the absolute
>> path for OUTPUTDIR 'Check_ALT_OUTPUTDIR'".  Stop.
>> make: *** [stamps/icedtea-ecj.stamp] Error 2
>>
>
> I would have thought it would be something like bsd-ppc instead of
> bsd-Power Macintosh. I don't have any point of reference on this as I have
> not built on other platforms. I assume it comes from uname.
>

uname -a
Darwin new-host.home 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:39:01
PST 2008; root:xnu-1228.9.59~1/RELEASE_PPC Power Macintosh powerpc
PowerMac8,2 Darwin

***************


>
>
>>
>> So now I use this as the make command.
>>
>> make ALT_OUTPUTDIR=`pwd`/build/bsd-PowerMacintosh
>> ALT_CUPS_HEADERS_PATH=/opt/local/include
>> FREETYPE_HEADERS_PATH=/opt/local/include
>> ALT_FREETYPE_LIB_PATH=/opt/local/lib
>>
>> It finds everthing in the configure but when it gets to the build it can't
>> find cups and freetype - there may be an option in configure but haven't
>> looked at that yet.
>> ...
>> checking cups/cups.h usability... yes
>> checking cups/cups.h presence... yes
>> checking for cups/cups.h... yes
>> checking cups/ppd.h usability... yes
>> checking cups/ppd.h presence... yes
>> checking for cups/ppd.h... yes
>> ...
>> checking for FREETYPE2... yes
>>
>>
>> Finally I get to the ant build and get this error and haven't had a chance
>> to look at this yet either.
>>
>> build-bootstrap-javac:
>>     [javac] Compiling 261 source files to
>> /Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/bootstrap/classes
>>     [javac]
>> /Users/eric/java/icedtea/openjdk-ecj/langtools/src/share/classes/com/sun/tools/javac/tree/JCTree.java:79:
>> interface expected here
>>     [javac] public abstract class JCTree implements Tree, Cloneable,
>> DiagnosticPosition {
>>     [javac]                                         ^
>>     [javac]
>> /Users/eric/java/icedtea/openjdk-ecj/langtools/src/share/classes/com/sun/tools/javac/tree/JCTree.java:1926:
>> cannot find symbol
>>     [javac] symbol  : class Kind
>>     [javac] location: class com.sun.tools.javac.tree.JCTree.TypeBoundKind
>>     [javac]         public Kind getKind() {
>>     [javac]                ^
>>
>>
>> Something isn't built obviously. Everybody on the lists has patient and
>> helpful so I'm sure I'll continue to make progress on the build. I am
>> interested in the Makefile changes submitted for the bsd port to see if they
>> will help. Don't know how to try them yet either. New to Mercurial.
>>
>
> Are you using icedtea 6 or 7?  I have been using 7 with the bsd option
> since it has all of the bsd changes in it.
>

Definitely, Icedtea 7. Andrew has made it very clear that Icedtea 7 is
really the only option.


>
>
>
>>
>> I'm glad you are working on the Intel version as the platform should be
>> virtually identical except for the processor type. compiler flags etc. I
>> need to use the zero assembly but I guess you wouldn't.
>>
>> Thanks for asking,
>>
> No problem.  Getting IcedTea on Power Macs would be very good.
>
>>
>> Eric
>>
>
> Michael
>

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090111/7f501189/attachment.html 

From ekrichardson at gmail.com  Sun Jan 11 23:41:03 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Sun, 11 Jan 2009 23:41:03 -0800
Subject: Power PC Build
In-Reply-To: <fee4d890901111952x1dd113b1p4eefe6762cc95d75@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<fee4d890901111417v79a2c4bch9978c062758d8c97@mail.gmail.com>
	<860cb0120901111931x5dcc73a8k6dbcd09733b6dec7@mail.gmail.com>
	<fee4d890901111952x1dd113b1p4eefe6762cc95d75@mail.gmail.com>
Message-ID: <860cb0120901112341n236d4f8cy9a06672f9b18ffe5@mail.gmail.com>

Michael,

On Sun, Jan 11, 2009 at 7:52 PM, Michael Franz <mvfranz at gmail.com> wrote:

> Eric,
>
> On Sun, Jan 11, 2009 at 10:31 PM, Eric Richardson <ekrichardson at gmail.com>wrote:
>
>> Michael,
>>
>> On Sun, Jan 11, 2009 at 2:17 PM, Michael Franz <mvfranz at gmail.com> wrote:
>>
>>> Eric,
>>>
>>> How is your progress with building on PowerPC?  I have been able to get
>>> hotspot to compile using Apple's JDK5, but I cannot get the complete JDK to
>>> build.
>>>
>>> Michael
>>
>>
>> I'm using this to configure.
>>
>> export LDFLAGS='-L/opt/local/lib';
>> ./configure --enable-zero=yes --with-project=bsd
>> --with-gcj-home=/Library/Java/Home
>> --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
>> --with-xalan2-jar=/opt/local/share/java/xalan.jar
>> --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
>> --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar
>> --with-rhino=/Users/eric/java-libs/js-engine.jar --disable-liveconnect
>> --with-libgcj-jar=/Library/Java/Home/jre/lib/rt.jar --disable-alsa
>>
>> So far, I have a couple of patching problems that I ignored.
>>
>>
>> Checking patches/hotspot/original/icedtea-version.patch
>> Applying patches/hotspot/original/icedtea-version.patch
>> patching file openjdk/hotspot/make/linux/makefiles/vm.make
>> patching file openjdk/hotspot/src/share/vm/utilities/vmError.cpp
>> Hunk #1 succeeded at 170 (offset 5 lines).
>> Hunk #2 succeeded at 347 (offset 7 lines).
>> Checking patches/icedtea-copy-plugs.patch
>> 1 out of 3 hunks FAILED -- saving rejects to file
>> openjdk/jdk/make/common/internal/BinaryPlugs.gmk.rej
>> ERROR patch patches/icedtea-copy-plugs.patch FAILED!
>> WARNING make clean-patch before retrying a fix
>> make: *** [stamps/patch.stamp] Error 2
>>
>
> I edit the breaking patches out of the Makefile.  That way, all the ones
> that do work get applied.  If you just re-run make after this error, the
> rest of the patches are not applied (I think) and that might be the cause of
> your compilation errors below.
>
>
>> Okay, I saw the Warning to "make clean-patch" so I commented out the
following patches that did not apply cleanly.

1) Checking patches/icedtea-copy-plugs.patch
2) Checking patches/ecj/icedtea.patch
3) Checking patches/icedtea-version.patch

<clip>
>

But I still get this

(cd  ./langtools/make && \
     /usr/bin/make JDK_TOPDIR=/Users/eric/java/icedtea/openjdk-ecj/jdk
JDK_MAKE_SHARED_DIR=/Users/eric/java/icedtea/openjdk-ecj/jdk/make/common/shared
EXTERNALSANITYCONTROL=true TARGET_CLASS_VERSION=5 MILESTONE=fcs
BUILD_NUMBER=b42 JDK_BUILD_NUMBER=b42 FULL_VERSION=1.7.0_0-bsd-b42
PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0_0 JDK_MKTG_VERSION=7u
JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0
ARCH_DATA_MODEL=64 COOKED_JDK_UPDATE_VERSION=0 COOKED_BUILD_NUMBER=42
ANT_HOME="/usr/share/ant"
ALT_OUTPUTDIR=/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools
ALT_BOOTDIR=/Users/eric/java/icedtea/bootstrap/jdk1.6.0 all)
JAVA_HOME=/Users/eric/java/icedtea/bootstrap/jdk1.6.0
ANT_OPTS=-Djava.io.tmpdir='/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/ant-tmp'
/usr/share/ant/bin/ant -diagnostics >
/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/ant-diagnostics.log
JAVA_HOME=/Users/eric/java/icedtea/bootstrap/jdk1.6.0
ANT_OPTS=-Djava.io.tmpdir='/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/ant-tmp'
/usr/share/ant/bin/ant -Djdk.version=1.7.0_0
-Dfull.version='1.7.0_0-bsd-b42'  -Drelease=1.7.0_0 -Dbuild.number=b42
-Djavac.target=5
-Dboot.java.home=/Users/eric/java/icedtea/bootstrap/jdk1.6.0
-Dbuild.dir=/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build
-Ddist.dir=/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/dist
build
Buildfile: build.xml

-def-check:

-check-boot.java.home:

-def-pcompile:
    [javac] Compiling 2 source files to
/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/toolclasses

-def-build-classes:

-def-build-jar:

-def-build-tool:

-def-build-bootstrap-tool:

build-bootstrap-javac:
 [pcompile] Generating 7 resource files to
/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/bootstrap/gensrc
     [copy] Copying 1 file to
/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/bootstrap/gensrc
 [pcompile] Generating 1 resource files to
/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/bootstrap/gensrc
    [javac] Compiling 8 source files to
/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/bootstrap/classes
    [javac] Compiling 261 source files to
/Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/bootstrap/classes


     [javac]
/Users/eric/java/icedtea/openjdk-ecj/langtools/src/share/classes/com/sun/tools/javac/tree/JCTree.java:79:
interface expected here
    [javac] public abstract class JCTree implements Tree, Cloneable,
DiagnosticPosition {
    [javac]                                         ^
    [javac]
/Users/eric/java/icedtea/openjdk-ecj/langtools/src/share/classes/com/sun/tools/javac/tree/JCTree.java:1926:
cannot find symbol
    [javac] symbol  : class Kind
    [javac] location: class com.sun.tools.javac.tree.JCTree.TypeBoundKind
    [javac]         public Kind getKind() {
    [javac]                ^


>> Something isn't built obviously. Everybody on the lists has patient and
>> helpful so I'm sure I'll continue to make progress on the build. I am
>> interested in the Makefile changes submitted for the bsd port to see if they
>> will help. Don't know how to try them yet either. New to Mercurial.
>>
>
> Are you using icedtea 6 or 7?  I have been using 7 with the bsd option
> since it has all of the bsd changes in it.
>
>
>>
>> I'm glad you are working on the Intel version as the platform should be
>> virtually identical except for the processor type. compiler flags etc. I
>> need to use the zero assembly but I guess you wouldn't.
>>
>> Thanks for asking,
>>
> No problem.  Getting IcedTea on Power Macs would be very good.
>
>>
>> Eric
>>
>
> Michael
>

I also found this error but is probably not related. The zip directory
doesn't exist.

for copy_dir in \
      `cat
/Users/eric/java/icedtea/tools-copy/tools-langtools-copy-files.txt` ; \
    do \
      mkdir -p hotspot-tools/$copy_dir ; \
      cp -pPRf openjdk/langtools/src/share/classes/$copy_dir/* \
        hotspot-tools/$copy_dir ; \
    done
cp: cannot stat
`openjdk/langtools/src/share/classes/com/sun/tools/javac/zip//*': No such
file or directory

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090111/a8d44a0a/attachment.html 

From christian.thalinger at gmail.com  Sun Jan 11 23:58:53 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Mon, 12 Jan 2009 08:58:53 +0100
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <fee4d890901111934s4ad3c9f9gf6be6e07a1679526@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<495FC5A4.8080600@redhat.com> <495FD307.3030606@redhat.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
	<fee4d890901091551p662a9ed8g227a491252d828e3@mail.gmail.com>
	<1231580745.26055.4.camel@localhost.localdomain>
	<fee4d890901101203kc1f653dl24cf290434aaeefe@mail.gmail.com>
	<17c6771e0901101656k7ef4b67eo1613f1ab4d68cad4@mail.gmail.com>
	<fee4d890901111934s4ad3c9f9gf6be6e07a1679526@mail.gmail.com>
Message-ID: <1231747133.18329.20.camel@localhost.localdomain>

On Sun, 2009-01-11 at 22:34 -0500, Michael Franz wrote:
> Hi,
> 
> Two issues that I have found when trying to compile on a non-linux
> platfor are:
> 1. LINUX_DIR this is defined as linux-$(BUILD_ARCH_DIR).  When
> building using the --with-project=bsd it needs to be
> bsd-$(BUILD_ARCH_DIR)

This changeset fixes it:

http://icedtea.classpath.org/hg/icedtea6/rev/2938e5bb0575

We just have to add BSD to SET_OS_DIRS and port it to IcedTea7.

- Christian



From bugzilla-daemon at icedtea.classpath.org  Mon Jan 12 02:37:14 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Mon, 12 Jan 2009 10:37:14 +0000
Subject: [Bug 281] web100 applet fails to display buttons
Message-ID: <E1LMKAU-0002oy-Nu@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=281





------- Comment #4 from vijay at online.nl  2009-01-12 10:37 -------
When loading the applet in http://ndt.switch.ch/

- A 'strace' on the java process
(/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/../../bin/java
sun.applet.PluginMain) reveals that's it's sitting in a futex:

futex(0x5089e0, FUTEX_WAIT, 3550, NULL

The java process itself has pid 3549. It's parent pid is firefox.

If I run a strace on (p|t)id 3550, I get:

Process 3550 attached - interrupt to quit
futex(0x1743054, FUTEX_WAIT_PRIVATE, 1, NULL

If I run a 'strace -f' on pid 3549, it seems that the subthreads are active:
$ strace -f -p 3549
Process 3735 attached with 22 threads - interrupt to quit
[pid  3580] futex(0x7f4e741d227c, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...>
[pid  3735] futex(0x7f4e73f5f154, FUTEX_WAIT_PRIVATE, 17, NULL <unfinished ...>
[pid  3574] futex(0x7f4e73d0d954, FUTEX_WAIT_PRIVATE, 39, NULL <unfinished ...>
[pid  3572] futex(0x1742054, FUTEX_WAIT_PRIVATE, 97, NULL <unfinished ...>
[pid  3571] read(4,  <unfinished ...>
[pid  3569] restart_syscall(<... resuming interrupted call ...> <unfinished
...>
[pid  3568] restart_syscall(<... resuming interrupted call ...> <unfinished
...>
[pid  3567] restart_syscall(<... resuming interrupted call ...> <unfinished
...>
[pid  3562] restart_syscall(<... resuming interrupted call ...> <unfinished
...>
[pid  3561] futex(0x7f4e74090254, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...>
[pid  3560] restart_syscall(<... resuming interrupted call ...> <unfinished
...>
[pid  3559] futex(0x7f4e74003654, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...>
[pid  3558] futex(0x7f4e7e08ef54, FUTEX_WAIT_PRIVATE, 105, NULL <unfinished
...>
[pid  3556] futex(0x1053d20, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid  3555] futex(0x7f4e7e069354, FUTEX_WAIT_PRIVATE, 5, NULL <unfinished ...>
[pid  3554] futex(0x7f4e7e061e54, FUTEX_WAIT_PRIVATE, 5, NULL <unfinished ...>
[pid  3553] restart_syscall(<... resuming interrupted call ...> <unfinished
...>
[pid  3552] futex(0x174f554, FUTEX_WAIT_PRIVATE, 7, NULL <unfinished ...>
[pid  3551] futex(0x174d854, FUTEX_WAIT_PRIVATE, 7, NULL <unfinished ...>
[pid  3550] futex(0x1743054, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...>
[pid  3549] futex(0x5089e0, FUTEX_WAIT, 3550, NULL <unfinished ...>
[pid  3557] futex(0x7f4e7e08b154, FUTEX_WAIT_PRIVATE, 41, NULL <unfinished ...>
[pid  3560] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed
out
)
[pid  3560] futex(0x7f4e74005f28, FUTEX_WAKE_PRIVATE, 1) = 0
...

The subthreads exhibit activity while pids 3549 and 3550 remain in the futex,
i.e. no activity. 

Is this the expected behaviour? 


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From gnu_andrew at member.fsf.org  Mon Jan 12 05:08:37 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 12 Jan 2009 13:08:37 +0000
Subject: Power PC Build
In-Reply-To: <860cb0120901112059s76ff0bet72ee38e3684b17c6@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<fee4d890901111417v79a2c4bch9978c062758d8c97@mail.gmail.com>
	<860cb0120901111931x5dcc73a8k6dbcd09733b6dec7@mail.gmail.com>
	<fee4d890901111952x1dd113b1p4eefe6762cc95d75@mail.gmail.com>
	<860cb0120901112059s76ff0bet72ee38e3684b17c6@mail.gmail.com>
Message-ID: <17c6771e0901120508n1ee078b2jee6362072ba9c97a@mail.gmail.com>

2009/1/12 Eric Richardson <ekrichardson at gmail.com>:
> Michael,
>
> On Sun, Jan 11, 2009 at 7:52 PM, Michael Franz <mvfranz at gmail.com> wrote:
>>
>> Eric,
>>
>> On Sun, Jan 11, 2009 at 10:31 PM, Eric Richardson <ekrichardson at gmail.com>
>> wrote:
>>>
>>> Michael,
>>>
>>> On Sun, Jan 11, 2009 at 2:17 PM, Michael Franz <mvfranz at gmail.com> wrote:
>>>>
>>>> Eric,
>>>>
>>>> How is your progress with building on PowerPC?  I have been able to get
>>>> hotspot to compile using Apple's JDK5, but I cannot get the complete JDK to
>>>> build.
>>>>
>>>> Michael
>>>
>>> I'm using this to configure.
>>>
>>> export LDFLAGS='-L/opt/local/lib';
>>> ./configure --enable-zero=yes --with-project=bsd
>>> --with-gcj-home=/Library/Java/Home
>>> --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar
>>> --with-xalan2-jar=/opt/local/share/java/xalan.jar
>>> --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar
>>> --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar
>>> --with-rhino=/Users/eric/java-libs/js-engine.jar --disable-liveconnect
>>> --with-libgcj-jar=/Library/Java/Home/jre/lib/rt.jar --disable-alsa
>>>
>>> So far, I have a couple of patching problems that I ignored.
>>>
>>>
>>> Checking patches/hotspot/original/icedtea-version.patch
>>> Applying patches/hotspot/original/icedtea-version.patch
>>> patching file openjdk/hotspot/make/linux/makefiles/vm.make
>>> patching file openjdk/hotspot/src/share/vm/utilities/vmError.cpp
>>> Hunk #1 succeeded at 170 (offset 5 lines).
>>> Hunk #2 succeeded at 347 (offset 7 lines).
>>> Checking patches/icedtea-copy-plugs.patch
>>> 1 out of 3 hunks FAILED -- saving rejects to file
>>> openjdk/jdk/make/common/internal/BinaryPlugs.gmk.rej
>>> ERROR patch patches/icedtea-copy-plugs.patch FAILED!
>>> WARNING make clean-patch before retrying a fix
>>> make: *** [stamps/patch.stamp] Error 2
>>
>> I edit the breaking patches out of the Makefile.  That way, all the ones
>> that do work get applied.  If you just re-run make after this error, the
>> rest of the patches are not applied (I think) and that might be the cause of
>> your compilation errors below.
>>
>>>
>>>
>>> Checking patches/ecj/icedtea.patch
>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>> openjdk-ecj/corba/make/common/Defs-linux.gmk.rej
>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>> openjdk-ecj/jaxp/make/build.xml.rej
>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>> openjdk-ecj/jaxws/make/build.xml.rej
>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>> openjdk-ecj/jaxws/make/Makefile.rej
>>> ERROR patch patches/ecj/icedtea.patch FAILED!
>>>

The ecj patch provides most of the fixes that make it possible to
build with other JDKs so it needs to be applied.  As I've said before,
I doubt it will work with Apple's proprietary JDK.

>>> Then I get a error because the system has a space in it.
>>>
>>> jdk/make/common/shared/Defs.gmk:478: "WARNING: Value of OUTPUTDIR
>>> contains a space: './build/bsd-Power Macintosh', check or set ALT_OUTPUTDIR"
>>> jdk/make/common/shared/Defs.gmk:498: "WARNING: Value of ABS_OUTPUTDIR
>>> contains a space: '/Users/eric/java/icedtea/openjdk-ecj/build/bsd-Power
>>> Macintosh', check or set ALT_ABS_OUTPUTDIR"
>>> jdk/make/common/shared/Defs.gmk:505: *** "ERROR: Trouble with the
>>> absolute path for OUTPUTDIR 'Check_ALT_OUTPUTDIR'".  Stop.
>>> make: *** [stamps/icedtea-ecj.stamp] Error 2
>>
>> I would have thought it would be something like bsd-ppc instead of
>> bsd-Power Macintosh. I don't have any point of reference on this as I have
>> not built on other platforms. I assume it comes from uname.
>
> uname -a
> Darwin new-host.home 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:39:01
> PST 2008; root:xnu-1228.9.59~1/RELEASE_PPC Power Macintosh powerpc
> PowerMac8,2 Darwin
>

'Power Macintosh' is insane... should be ppc, sounds like some
brokenness from Apple.

> ***************
>
>>
>>
>>>
>>> So now I use this as the make command.
>>>
>>> make ALT_OUTPUTDIR=`pwd`/build/bsd-PowerMacintosh
>>> ALT_CUPS_HEADERS_PATH=/opt/local/include
>>> FREETYPE_HEADERS_PATH=/opt/local/include
>>> ALT_FREETYPE_LIB_PATH=/opt/local/lib
>>>
>>> It finds everthing in the configure but when it gets to the build it
>>> can't find cups and freetype - there may be an option in configure but
>>> haven't looked at that yet.
>>> ...
>>> checking cups/cups.h usability... yes
>>> checking cups/cups.h presence... yes
>>> checking for cups/cups.h... yes
>>> checking cups/ppd.h usability... yes
>>> checking cups/ppd.h presence... yes
>>> checking for cups/ppd.h... yes
>>> ...
>>> checking for FREETYPE2... yes
>>>
>>>
>>> Finally I get to the ant build and get this error and haven't had a
>>> chance to look at this yet either.
>>>
>>> build-bootstrap-javac:
>>>     [javac] Compiling 261 source files to
>>> /Users/eric/java/icedtea/build/bsd-PowerMacintosh/langtools/build/bootstrap/classes
>>>     [javac]
>>> /Users/eric/java/icedtea/openjdk-ecj/langtools/src/share/classes/com/sun/tools/javac/tree/JCTree.java:79:
>>> interface expected here
>>>     [javac] public abstract class JCTree implements Tree, Cloneable,
>>> DiagnosticPosition {
>>>     [javac]                                         ^
>>>     [javac]
>>> /Users/eric/java/icedtea/openjdk-ecj/langtools/src/share/classes/com/sun/tools/javac/tree/JCTree.java:1926:
>>> cannot find symbol
>>>     [javac] symbol  : class Kind
>>>     [javac] location: class com.sun.tools.javac.tree.JCTree.TypeBoundKind
>>>     [javac]         public Kind getKind() {
>>>     [javac]                ^
>>>
>>>
>>> Something isn't built obviously. Everybody on the lists has patient and
>>> helpful so I'm sure I'll continue to make progress on the build. I am
>>> interested in the Makefile changes submitted for the bsd port to see if they
>>> will help. Don't know how to try them yet either. New to Mercurial.
>>
>> Are you using icedtea 6 or 7?  I have been using 7 with the bsd option
>> since it has all of the bsd changes in it.
>
> Definitely, Icedtea 7. Andrew has made it very clear that Icedtea 7 is
> really the only option.
>

Only because the BSD porters are working in a separate OpenJDK7 tree,
making its use incredibly niche (i.e. it can't provide a TCK-passing
Free Java for *BSD until such a time as there is a Free TCK for 7,
that's some years off).  I think the work would be better placed
directly in IcedTea where it can be used with 6 + 7.

>>
>>
>>>
>>> I'm glad you are working on the Intel version as the platform should be
>>> virtually identical except for the processor type. compiler flags etc. I
>>> need to use the zero assembly but I guess you wouldn't.
>>>
>>> Thanks for asking,
>>
>> No problem.  Getting IcedTea on Power Macs would be very good.
>>>

Agreed.  I'll look at supporting BSD better in 7 once I've finished
work on NIO2 support.

>>> Eric
>>
>> Michael
>
> Eric
>
>
>
>
>

Cheers,
-- 
Andrew :-)

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


From gnu_andrew at member.fsf.org  Mon Jan 12 05:11:23 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 12 Jan 2009 13:11:23 +0000
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <1231747133.18329.20.camel@localhost.localdomain>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
	<fee4d890901091551p662a9ed8g227a491252d828e3@mail.gmail.com>
	<1231580745.26055.4.camel@localhost.localdomain>
	<fee4d890901101203kc1f653dl24cf290434aaeefe@mail.gmail.com>
	<17c6771e0901101656k7ef4b67eo1613f1ab4d68cad4@mail.gmail.com>
	<fee4d890901111934s4ad3c9f9gf6be6e07a1679526@mail.gmail.com>
	<1231747133.18329.20.camel@localhost.localdomain>
Message-ID: <17c6771e0901120511s2f627e0fj4cbddbaf48f6973@mail.gmail.com>

2009/1/12 Christian Thalinger <christian.thalinger at gmail.com>:
> On Sun, 2009-01-11 at 22:34 -0500, Michael Franz wrote:
>> Hi,
>>
>> Two issues that I have found when trying to compile on a non-linux
>> platfor are:
>> 1. LINUX_DIR this is defined as linux-$(BUILD_ARCH_DIR).  When
>> building using the --with-project=bsd it needs to be
>> bsd-$(BUILD_ARCH_DIR)
>
> This changeset fixes it:
>
> http://icedtea.classpath.org/hg/icedtea6/rev/2938e5bb0575
>
> We just have to add BSD to SET_OS_DIRS and port it to IcedTea7.
>
> - Christian
>
>

Yes, but please don't port it separately.  I will do a merge soon.
-- 
Andrew :-)

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


From christian.thalinger at gmail.com  Mon Jan 12 06:17:57 2009
From: christian.thalinger at gmail.com (Christian Thalinger)
Date: Mon, 12 Jan 2009 15:17:57 +0100
Subject: Building IcedTea7 Using BSD option On OS X
In-Reply-To: <17c6771e0901120511s2f627e0fj4cbddbaf48f6973@mail.gmail.com>
References: <fee4d890812292025m1b286087j3eb5fad4628d67b2@mail.gmail.com>
	<fee4d890901031323t6d9aa7a1nd59199566ab06a5@mail.gmail.com>
	<495FE0E0.60703@redhat.com>
	<1231062689.28600.2.camel@localhost.localdomain>
	<fee4d890901091551p662a9ed8g227a491252d828e3@mail.gmail.com>
	<1231580745.26055.4.camel@localhost.localdomain>
	<fee4d890901101203kc1f653dl24cf290434aaeefe@mail.gmail.com>
	<17c6771e0901101656k7ef4b67eo1613f1ab4d68cad4@mail.gmail.com>
	<fee4d890901111934s4ad3c9f9gf6be6e07a1679526@mail.gmail.com>
	<1231747133.18329.20.camel@localhost.localdomain>
	<17c6771e0901120511s2f627e0fj4cbddbaf48f6973@mail.gmail.com>
Message-ID: <1231769877.18329.73.camel@localhost.localdomain>

On Mon, 2009-01-12 at 13:11 +0000, Andrew John Hughes wrote:
> Yes, but please don't port it separately.  I will do a merge soon.

No, it's all yours :-)

-- Christian



From Coleen.Phillimore at Sun.COM  Mon Jan 12 03:30:37 2009
From: Coleen.Phillimore at Sun.COM (coleenp)
Date: Mon, 12 Jan 2009 06:30:37 -0500
Subject: how to build without precompiled headers?
In-Reply-To: <4963E5A1.3060605@ubuntu.com>
References: <49613144.90706@ubuntu.com> <496242E8.10509@sun.com>
	<4963E5A1.3060605@ubuntu.com>
Message-ID: <496B29DD.7090507@sun.com>


I filed a Hotspot bug to change this and also fixed some C++ interpreter 
compilation errors with gcc 4.3.2 and 4.1.3 both on ubuntu.  Please note 
that the C++ interpreter isn't shipped on Sun's releases so may have 
bugs in 64 bit mode.  It seems to work on 32 bit linux.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6791168

Please review this code change:

http://webrev.invokedynamic.info/coleenp/6791168

thanks,
Coleen

Matthias Klose wrote:
> Thanks,
>
> please see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38593
> and
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38725
>
> looks like current GCC versions accept invalid code:
>
> "That's really a duplicate of PR38725: The code contains many lines of the form
>
>   goto *dispatch_table[opcode];
>
> where dispatch_table[opcode] is of the type uintptr_t which is a typedef
> to unsigned int. Writing
>
>   goto *(void*)dispatch_table[opcode];
>
> instead makes the ICE disappear."
>
>
> Coleen Phillimore - Sun Microsystems schrieb:
>   
>> I tried this on my new 8.10 ubuntu system at home and commenting out
>> USE_PRECOMPILED_HEADER didn't use the precompiled header. The file
>> _precompiled.incl is still produced but it's empty. I believe you have
>> to do a make clean before your gcc.make change is used.
>>
>> The version of gcc that I used was very picky about inlined functions
>> not being defined in places where the other platforms were happy, so
>> there were multiple warnings with this message. I have a patch file that
>> resolves this, if you want it.
>> Also, on my 8.10 ubuntu, gcc version 4.1.forgot, I got an error building
>> fastdebug (server compiler) which I haven't resolved.
>>
>> /home/coleenp/hotspot/src/share/vm/libadt/port.hpp:40: error: 'void
>> bcopy(const void*, void*, size_t)' redeclared inline without
>> 'gnu_inline' attribute
>>
>> If you're trying to track down a compiler error building hotspot, try
>> getting a preprocessed output file to narrow it down.
>> cd linux*/<target>
>> make <file that had error>.i
>>
>> Hope this helps.
>> Coleen
>>
>> On 01/04/09 16:59, Matthias Klose wrote:
>>     
>>> Trying to track down an ICE (internal compiler error), I need to build
>>> hotspot
>>> without precompiled header files.  There is a macro
>>> USE_PRECOMPILED_HEADER
>>> defined in openjdk/hotspot/make/*/makefiles/gcc.make, but just
>>> removing the
>>> conditional around this definition still builds using precompiled
>>> header files.
>>> How can you build without precompiled header files (even if it's a hack)?
>>>
>>>   Matthias
>>>   
>>>       
>
>   



From aph at redhat.com  Mon Jan 12 09:31:03 2009
From: aph at redhat.com (Andrew Haley)
Date: Mon, 12 Jan 2009 17:31:03 +0000
Subject: changeset in /hg/icedtea6: 2009-01-12  Andrew Haley  <aph@redhat...
Message-ID: <hg.e34ba0ba2281.1231781463.2873452341184383832@icedtea.classpath.org>

changeset e34ba0ba2281 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=e34ba0ba2281
description:
	2009-01-12  Andrew Haley  <aph at redhat.com>

	        * ports/hotspot/src/share/vm/shark/sharkBlock.cpp (SharkBlock::do_ldc):
	        Add logic for ldc(Class).

diffstat:

2 files changed, 29 insertions(+), 2 deletions(-)
ChangeLog                                       |    5 ++++
ports/hotspot/src/share/vm/shark/sharkBlock.cpp |   26 +++++++++++++++++++++--

diffs (72 lines):

diff -r bce8d56dfa03 -r e34ba0ba2281 ChangeLog
--- a/ChangeLog	Sun Jan 11 18:56:44 2009 +0100
+++ b/ChangeLog	Mon Jan 12 17:29:21 2009 +0000
@@ -1,3 +1,8 @@ 2009-01-11  Mark Wielaard  <mark at klomp.o
+2009-01-12  Andrew Haley  <aph at redhat.com>
+
+	* ports/hotspot/src/share/vm/shark/sharkBlock.cpp (SharkBlock::do_ldc):
+        Add logic for ldc(Class).
+
 2009-01-11  Mark Wielaard  <mark at klomp.org>
 
 	* Makefile.am: Escape single quotes in empty bootclasspath.
diff -r bce8d56dfa03 -r e34ba0ba2281 ports/hotspot/src/share/vm/shark/sharkBlock.cpp
--- a/ports/hotspot/src/share/vm/shark/sharkBlock.cpp	Sun Jan 11 18:56:44 2009 +0100
+++ b/ports/hotspot/src/share/vm/shark/sharkBlock.cpp	Mon Jan 12 17:29:21 2009 +0000
@@ -1236,10 +1236,11 @@ void SharkBlock::do_ldc()
     SharkConstantPool constants(this);
 
     BasicBlock *resolved   = function()->CreateBlock("resolved");
+    BasicBlock *resolved_class = function()->CreateBlock("resolved_class");
     BasicBlock *unresolved = function()->CreateBlock("unresolved");
     BasicBlock *unknown    = function()->CreateBlock("unknown");
     BasicBlock *done       = function()->CreateBlock("done");
-    
+
     SwitchInst *switchinst = builder()->CreateSwitch(
       constants.tag_at(iter()->get_constant_index()),
       unknown, 5);
@@ -1247,7 +1248,7 @@ void SharkBlock::do_ldc()
     switchinst->addCase(
       LLVMValue::jbyte_constant(JVM_CONSTANT_String), resolved);
     switchinst->addCase(
-      LLVMValue::jbyte_constant(JVM_CONSTANT_Class), resolved);
+      LLVMValue::jbyte_constant(JVM_CONSTANT_Class), resolved_class);
     switchinst->addCase(
       LLVMValue::jbyte_constant(JVM_CONSTANT_UnresolvedString), unresolved);
     switchinst->addCase(
@@ -1260,6 +1261,26 @@ void SharkBlock::do_ldc()
     Value *resolved_value = constants.object_at(iter()->get_constant_index());
     builder()->CreateBr(done);
 
+    builder()->SetInsertPoint(resolved_class);
+    Value *resolved_class_value
+      = constants.object_at(iter()->get_constant_index());
+    resolved_class_value
+      = builder()->CreatePtrToInt(resolved_class_value,
+                                  SharkType::intptr_type());
+    resolved_class_value
+      = (builder()->CreateAdd
+         (resolved_class_value,
+          (LLVMValue::intptr_constant
+           (klassOopDesc::klass_part_offset_in_bytes()
+            + Klass::java_mirror_offset_in_bytes()))));
+    resolved_class_value
+      // FIXME: We need a memory barrier before this load.
+      = (builder()->CreateLoad
+         (builder()->CreateIntToPtr
+          (resolved_class_value,
+           PointerType::getUnqual(SharkType::jobject_type()))));
+    builder()->CreateBr(done);
+
     builder()->SetInsertPoint(unresolved);
     builder()->CreateUnimplemented(__FILE__, __LINE__);
     Value *unresolved_value = LLVMValue::null();
@@ -1272,6 +1293,7 @@ void SharkBlock::do_ldc()
     builder()->SetInsertPoint(done);
     PHINode *phi = builder()->CreatePHI(SharkType::jobject_type(), "constant");
     phi->addIncoming(resolved_value, resolved);
+    phi->addIncoming(resolved_class_value, resolved_class);
     phi->addIncoming(unresolved_value, unresolved);
     value = SharkValue::create_jobject(phi);
   }


From aph at redhat.com  Mon Jan 12 09:31:09 2009
From: aph at redhat.com (Andrew Haley)
Date: Mon, 12 Jan 2009 17:31:09 +0000
Subject: Shark: fix ldc(Class)
Message-ID: <496B7E5D.9090600@redhat.com>

I've been trying to track down a mysterious bug in Shark for a couple
of weeks, and I finally got it.  It turns out that there's no code
generated for ldc(Class).  What fun!

Oh well, I learned a lot...  :-)

Andrew.


2009-01-12  Andrew Haley  <aph at redhat.com>

        * ports/hotspot/src/share/vm/shark/sharkBlock.cpp (SharkBlock::do_ldc):
        Add logic for ldc(Class).

diff -r 79f28ead8d7b ports/hotspot/src/share/vm/shark/sharkBlock.cpp
--- a/ports/hotspot/src/share/vm/shark/sharkBlock.cpp   Mon Jan 05 11:42:35 2009 +0000
+++ b/ports/hotspot/src/share/vm/shark/sharkBlock.cpp   Mon Jan 12 17:25:51 2009 +0000
@@ -1236,10 +1236,11 @@
     SharkConstantPool constants(this);

     BasicBlock *resolved   = function()->CreateBlock("resolved");
+    BasicBlock *resolved_class = function()->CreateBlock("resolved_class");
     BasicBlock *unresolved = function()->CreateBlock("unresolved");
     BasicBlock *unknown    = function()->CreateBlock("unknown");
     BasicBlock *done       = function()->CreateBlock("done");
-
+
     SwitchInst *switchinst = builder()->CreateSwitch(
       constants.tag_at(iter()->get_constant_index()),
       unknown, 5);
@@ -1247,7 +1248,7 @@
     switchinst->addCase(
       LLVMValue::jbyte_constant(JVM_CONSTANT_String), resolved);
     switchinst->addCase(
-      LLVMValue::jbyte_constant(JVM_CONSTANT_Class), resolved);
+      LLVMValue::jbyte_constant(JVM_CONSTANT_Class), resolved_class);
     switchinst->addCase(
       LLVMValue::jbyte_constant(JVM_CONSTANT_UnresolvedString), unresolved);
     switchinst->addCase(
@@ -1258,6 +1259,26 @@

     builder()->SetInsertPoint(resolved);
     Value *resolved_value = constants.object_at(iter()->get_constant_index());
+    builder()->CreateBr(done);
+
+    builder()->SetInsertPoint(resolved_class);
+    Value *resolved_class_value
+      = constants.object_at(iter()->get_constant_index());
+    resolved_class_value
+      = builder()->CreatePtrToInt(resolved_class_value,
+                                  SharkType::intptr_type());
+    resolved_class_value
+      = (builder()->CreateAdd
+         (resolved_class_value,
+          (LLVMValue::intptr_constant
+           (klassOopDesc::klass_part_offset_in_bytes()
+            + Klass::java_mirror_offset_in_bytes()))));
+    resolved_class_value
+      // FIXME: We need a memory barrier before this load.
+      = (builder()->CreateLoad
+         (builder()->CreateIntToPtr
+          (resolved_class_value,
+           PointerType::getUnqual(SharkType::jobject_type()))));
     builder()->CreateBr(done);

     builder()->SetInsertPoint(unresolved);
@@ -1272,6 +1293,7 @@
     builder()->SetInsertPoint(done);
     PHINode *phi = builder()->CreatePHI(SharkType::jobject_type(), "constant");
     phi->addIncoming(resolved_value, resolved);
+    phi->addIncoming(resolved_class_value, resolved_class);
     phi->addIncoming(unresolved_value, unresolved);
     value = SharkValue::create_jobject(phi);
   }


From mvfranz at gmail.com  Mon Jan 12 17:05:48 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Mon, 12 Jan 2009 20:05:48 -0500
Subject: Power PC Build
In-Reply-To: <17c6771e0901120508n1ee078b2jee6362072ba9c97a@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<fee4d890901111417v79a2c4bch9978c062758d8c97@mail.gmail.com>
	<860cb0120901111931x5dcc73a8k6dbcd09733b6dec7@mail.gmail.com>
	<fee4d890901111952x1dd113b1p4eefe6762cc95d75@mail.gmail.com>
	<860cb0120901112059s76ff0bet72ee38e3684b17c6@mail.gmail.com>
	<17c6771e0901120508n1ee078b2jee6362072ba9c97a@mail.gmail.com>
Message-ID: <fee4d890901121705k70f16dar8d3dde7c75212f5b@mail.gmail.com>

Andrew,


> The ecj patch provides most of the fixes that make it possible to
> build with other JDKs so it needs to be applied.  As I've said before,
> I doubt it will work with Apple's proprietary JDK.
>

I have applied all of the ecj patches.  The thing that was causing the patch
to fail is this

--- patches/ecj/icedtea-pr261.patch.orig    2009-01-12 19:13:15.000000000
-0500
+++ patches/ecj/icedtea-pr261.patch    2009-01-12 19:13:38.000000000 -0500
@@ -21,7 +21,7 @@
 --- openjdk-ecj.orig/jdk/make/java/nio/Makefile    2008-12-02
15:52:07.000000000 +0000
 +++ openjdk-ecj/jdk/make/java/nio/Makefile    2008-12-02 15:59:32.000000000
+0000
 @@ -85,6 +85,9 @@
- ifeq ($(PLATFORM), linux)
+ ifneq (,$(findstring $(PLATFORM), linux bsd))
  FILES_java += \
          sun/nio/ch/AbstractPollSelectorImpl.java \

I still cannot get anything other than hotspot to compile correctly.  There
are a bunch of manual steps that I have to do for that (hotspot).

How can a patch be created that would handle both versions of the file?


> Only because the BSD porters are working in a separate OpenJDK7 tree,
> making its use incredibly niche (i.e. it can't provide a TCK-passing
> Free Java for *BSD until such a time as there is a Free TCK for 7,
> that's some years off).  I think the work would be better placed
> directly in IcedTea where it can be used with 6 + 7.


I think the plan is to get the BSD port working correctly and then merge the
changes into the main repo, but I could be wrong on that.  I know that the
merges from the main repo are applied to the bsd port.


> Cheers,
> --
> Andrew :-)
>
> Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090112/42ba108b/attachment.html 

From gbenson at redhat.com  Tue Jan 13 00:25:52 2009
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 13 Jan 2009 08:25:52 +0000
Subject: Shark: fix ldc(Class)
In-Reply-To: <496B7E5D.9090600@redhat.com>
References: <496B7E5D.9090600@redhat.com>
Message-ID: <20090113082552.GA3588@redhat.com>

Andrew Haley wrote:
> I've been trying to track down a mysterious bug in Shark for a
> couple of weeks, and I finally got it.  It turns out that there's
> no code generated for ldc(Class).  What fun!
> 
> Oh well, I learned a lot...  :-)

Was it not hitting an Unimplemented() or similar?

Cheers,
Gary

-- 
http://gbenson.net/


From aph at redhat.com  Tue Jan 13 01:52:37 2009
From: aph at redhat.com (Andrew Haley)
Date: Tue, 13 Jan 2009 09:52:37 +0000
Subject: Shark: fix ldc(Class)
In-Reply-To: <20090113082552.GA3588@redhat.com>
References: <496B7E5D.9090600@redhat.com> <20090113082552.GA3588@redhat.com>
Message-ID: <496C6465.5080402@redhat.com>

Gary Benson wrote:
> Andrew Haley wrote:
>> I've been trying to track down a mysterious bug in Shark for a
>> couple of weeks, and I finally got it.  It turns out that there's
>> no code generated for ldc(Class).  What fun!
>>
>> Oh well, I learned a lot...  :-)
> 
> Was it not hitting an Unimplemented() or similar?

It simply generated a read from the constant pool.  The cpool entry
points to a classOopDesc, so code has to be generated to get from the
classOopDesc to the Class.

Looking at sharkConstantPool.cpp, I now see java_mirror() which does the
same thing as the code I added.  I'll change my code to call that
function.

Incidentally, I think there has to me a memory barrier between reading
the tag and reading the constant pool entry.  The c++ interpeter
does this by calling byte_at_acquire().

Andrew.


From gbenson at redhat.com  Tue Jan 13 02:05:50 2009
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 13 Jan 2009 10:05:50 +0000
Subject: Shark: fix ldc(Class)
In-Reply-To: <496C6465.5080402@redhat.com>
References: <496B7E5D.9090600@redhat.com> <20090113082552.GA3588@redhat.com>
	<496C6465.5080402@redhat.com>
Message-ID: <20090113100550.GD3588@redhat.com>

Andrew Haley wrote:
> Gary Benson wrote:
> > Andrew Haley wrote:
> > > I've been trying to track down a mysterious bug in Shark for
> > > a couple of weeks, and I finally got it.  It turns out that
> > > there's no code generated for ldc(Class).  What fun!
> > >
> > > Oh well, I learned a lot...  :-)
> > 
> > Was it not hitting an Unimplemented() or similar?
> 
> It simply generated a read from the constant pool.  The cpool entry
> points to a classOopDesc, so code has to be generated to get from
> the classOopDesc to the Class.

Yuk :(

> Incidentally, I think there has to me a memory barrier between
> reading the tag and reading the constant pool entry.  The c++
> interpeter does this by calling byte_at_acquire().

A lot of those OrderAccess functions are barrierless on every platform:

 hotspot/src/share/vm/oops/constantPoolOop.hpp: constantTag tag_at(int which) const { return (constantTag) tags()->byte_at_acquire(which); }
  ...
 hotspot/src/share/vm/oops/typeArrayOop.hpp: jbyte byte_at_acquire(int which) const { return OrderAccess::load_acquire(byte_at_addr(which)); }
  ...
 hotspot/src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
 hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:         inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
 hotspot/src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp: inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
 hotspot/src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
 hotspot/src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }

I just did the same for Zero.  It seemed hacky, but I wasn't sure what
else to do...

Cheers,
Gary

--
http://gbenson.net/


From aph at redhat.com  Tue Jan 13 02:41:04 2009
From: aph at redhat.com (Andrew Haley)
Date: Tue, 13 Jan 2009 10:41:04 +0000
Subject: Shark: fix ldc(Class)
In-Reply-To: <20090113100550.GD3588@redhat.com>
References: <496B7E5D.9090600@redhat.com>
	<20090113082552.GA3588@redhat.com>	<496C6465.5080402@redhat.com>
	<20090113100550.GD3588@redhat.com>
Message-ID: <496C6FC0.8020609@redhat.com>

Gary Benson wrote:
> Andrew Haley wrote:
>> Gary Benson wrote:
>>> Andrew Haley wrote:
>>>> I've been trying to track down a mysterious bug in Shark for
>>>> a couple of weeks, and I finally got it.  It turns out that
>>>> there's no code generated for ldc(Class).  What fun!
>>>>
>>>> Oh well, I learned a lot...  :-)
>>> Was it not hitting an Unimplemented() or similar?
>> It simply generated a read from the constant pool.  The cpool entry
>> points to a classOopDesc, so code has to be generated to get from
>> the classOopDesc to the Class.
> 
> Yuk :(
> 
>> Incidentally, I think there has to me a memory barrier between
>> reading the tag and reading the constant pool entry.  The c++
>> interpeter does this by calling byte_at_acquire().
> 
> A lot of those OrderAccess functions are barrierless on every platform:
> 
>  hotspot/src/share/vm/oops/constantPoolOop.hpp: constantTag tag_at(int which) const { return (constantTag) tags()->byte_at_acquire(which); }
>   ...
>  hotspot/src/share/vm/oops/typeArrayOop.hpp: jbyte byte_at_acquire(int which) const { return OrderAccess::load_acquire(byte_at_addr(which)); }
>   ...
>  hotspot/src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
>  hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:         inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
>  hotspot/src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp: inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
>  hotspot/src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
>  hotspot/src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
> 
> I just did the same for Zero.  It seemed hacky, but I wasn't sure what
> else to do...

Many of the CPUs we use won't be affected.  SPARC apparently can use
either Total Store ordering (TSO) or Partial Store Order (PSO) or
Relaxed Memory Order (RMO).  :-)

http://developers.sun.com/solaris/articles/atomic_sparc/

>From what you say, I think the Java VM assumes TSO.

TSO is, approximately, what we have on x86_64 too.

PowerPC uses, as far as I can see, Relaxed Store Ordering.
So, Load Acquire requires a sync.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html
shows the PPC Code Sequences needed for each operation.  Example 3,
Store/Load, shows what's needed for reading and updating constant
pool entries:

#  Thread 0:

	x.store(1, memory_order_relaxed);
	y.store(1, memory_order_release);
	

# Thread 1:

	r1 = y.load(memory_order_acquire);
	if (r1 == 1)
		r2 = x.load(memory_order_relaxed);

(x is the value, y the tag.)

Andrew.

see also http://www.cs.utah.edu/mpv/papers/neiger/fmcad2001.pdf


From doko at ubuntu.com  Tue Jan 13 03:23:21 2009
From: doko at ubuntu.com (Matthias Klose)
Date: Tue, 13 Jan 2009 12:23:21 +0100
Subject: how to build without precompiled headers?
In-Reply-To: <496B29DD.7090507@sun.com>
References: <49613144.90706@ubuntu.com> <496242E8.10509@sun.com>
	<4963E5A1.3060605@ubuntu.com> <496B29DD.7090507@sun.com>
Message-ID: <496C79A9.3020307@ubuntu.com>

coleenp schrieb:
> 
> I filed a Hotspot bug to change this and also fixed some C++ interpreter
> compilation errors with gcc 4.3.2 and 4.1.3 both on ubuntu.  Please note
> that the C++ interpreter isn't shipped on Sun's releases so may have
> bugs in 64 bit mode.  It seems to work on 32 bit linux.
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6791168
> 
> Please review this code change:
> 
> http://webrev.invokedynamic.info/coleenp/6791168

Tested with a IcedTea build, showing no regressions in the jtreg testsuite.
Checking this into IcedTea.

  Matthias


From doko at ubuntu.com  Tue Jan 13 03:32:25 2009
From: doko at ubuntu.com (doko at ubuntu.com)
Date: Tue, 13 Jan 2009 11:32:25 +0000
Subject: changeset in /hg/icedtea6: 2009-01-13  Matthias Klose  <doko@ubu...
Message-ID: <hg.c672bd2ca978.1231846345.2873452341184383832@icedtea.classpath.org>

changeset c672bd2ca978 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=c672bd2ca978
description:
	2009-01-13  Matthias Klose  <doko at ubuntu.com>

	        * patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch: Remove,
	        replaced by ...
	        * patches/hotspot/14.0b08/icedtea-6791168.patch: New.
	        * patches/hotspot/14.0b08/icedtea-includedb.patch: Update.
	        * HACKING: Update for the above.
	        * Makefile.am: Update for the above.

diffstat:

6 files changed, 339 insertions(+), 24 deletions(-)
ChangeLog                                              |    9 
HACKING                                                |    4 
Makefile.am                                            |    2 
patches/hotspot/14.0b08/icedtea-6791168.patch          |  230 ++++++++++++++++
patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch |   11 
patches/hotspot/14.0b08/icedtea-includedb.patch        |  107 ++++++-

diffs (403 lines):

diff -r e34ba0ba2281 -r c672bd2ca978 ChangeLog
--- a/ChangeLog	Mon Jan 12 17:29:21 2009 +0000
+++ b/ChangeLog	Tue Jan 13 12:30:34 2009 +0100
@@ -1,3 +1,12 @@ 2009-01-12  Andrew Haley  <aph at redhat.co
+2009-01-13  Matthias Klose  <doko at ubuntu.com>
+
+	* patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch: Remove,
+	replaced by ...
+	* patches/hotspot/14.0b08/icedtea-6791168.patch: New.
+	* patches/hotspot/14.0b08/icedtea-includedb.patch: Update.
+	* HACKING: Update for the above.
+	* Makefile.am: Update for the above.
+
 2009-01-12  Andrew Haley  <aph at redhat.com>
 
 	* ports/hotspot/src/share/vm/shark/sharkBlock.cpp (SharkBlock::do_ldc):
diff -r e34ba0ba2281 -r c672bd2ca978 HACKING
--- a/HACKING	Mon Jan 12 17:29:21 2009 +0000
+++ b/HACKING	Tue Jan 13 12:30:34 2009 +0100
@@ -80,9 +80,9 @@ The following patches are currently appl
 * icedtea-cc-interp-jvmti.patch: Disable some JVMTI capabilities which are unsupported or do not work with the C++ interpreter.
 * icedtea-a11y-property-change.patch: Dont fire PropertyChangeEvent if the property hasnt changed.
 * icedtea-demo-swingapplet.patch: Add missing html file needed to run the demo.
-* icedtea-hotspot-dispatch.patch: Fix build failure with GCC-4.4 (PR 38725).
+* icedtea-6791168.patch: Fix build failure with GCC-4.4 (PR 38725) and compiler warnings.
 * icedtea-no-precompiled.patch: Don't use precompiled header files in hotspot.
-* icedtea-includedb.patch: Add missing include.
+* icedtea-includedb.patch: Add missing include files.
 * icedtea-awt-window-size.patch: Fix X11 window size calculation (S6721088).
 
 The following patches are only applied to OpenJDK6 in IcedTea6:
diff -r e34ba0ba2281 -r c672bd2ca978 Makefile.am
--- a/Makefile.am	Mon Jan 12 17:29:21 2009 +0000
+++ b/Makefile.am	Tue Jan 13 12:30:34 2009 +0100
@@ -650,7 +650,7 @@ ICEDTEA_PATCHES += \
 	patches/icedtea-format-warnings.patch \
 	patches/icedtea-fortify-source.patch \
 	patches/hotspot/$(HSBUILD)/icedtea-sparc-buildfixes.patch \
-	patches/hotspot/$(HSBUILD)/icedtea-hotspot-dispatch.patch \
+	patches/hotspot/$(HSBUILD)/icedtea-6791168.patch \
 	patches/hotspot/$(HSBUILD)/icedtea-includedb.patch
 endif
 
diff -r e34ba0ba2281 -r c672bd2ca978 patches/hotspot/14.0b08/icedtea-6791168.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/hotspot/14.0b08/icedtea-6791168.patch	Tue Jan 13 12:30:34 2009 +0100
@@ -0,0 +1,230 @@
+--- openjdk/hotspot/src/cpu/x86/vm/cppInterpreter_x86.cpp.orig	2009-01-13 10:15:42.000000000 +0000
++++ openjdk/hotspot/src/cpu/x86/vm/cppInterpreter_x86.cpp	2009-01-13 10:17:05.000000000 +0000
+@@ -594,7 +594,7 @@
+   __ call_VM(noreg, CAST_FROM_FN_PTR(address, InterpreterRuntime::frequency_counter_overflow), rax);
+ 
+   // for c++ interpreter can rsi really be munged?
+-  __ lea(state, Address(rbp, -sizeof(BytecodeInterpreter)));                               // restore state
++  __ lea(state, Address(rbp, -(int)sizeof(BytecodeInterpreter)));                               // restore state
+   __ movptr(rbx, Address(state, byte_offset_of(BytecodeInterpreter, _method)));            // restore method
+   __ movptr(rdi, Address(state, byte_offset_of(BytecodeInterpreter, _locals)));            // get locals pointer
+ 
+@@ -658,7 +658,7 @@
+     const Address size_of_stack    (rbx, methodOopDesc::max_stack_offset());
+     // Always give one monitor to allow us to start interp if sync method.
+     // Any additional monitors need a check when moving the expression stack
+-    const one_monitor = frame::interpreter_frame_monitor_size() * wordSize;
++    const int one_monitor = frame::interpreter_frame_monitor_size() * wordSize;
+   __ load_unsigned_word(rax, size_of_stack);                            // get size of expression stack in words
+   __ lea(rax, Address(noreg, rax, Interpreter::stackElementScale(), one_monitor));
+   __ lea(rax, Address(rax, rdx, Interpreter::stackElementScale(), overhead_size));
+@@ -1829,7 +1829,7 @@
+   Label unwind_and_forward;
+ 
+   // restore state pointer.
+-  __ lea(state, Address(rbp,  -sizeof(BytecodeInterpreter)));
++  __ lea(state, Address(rbp,  -(int)sizeof(BytecodeInterpreter)));
+ 
+   __ movptr(rbx, STATE(_method));                       // get method
+ #ifdef _LP64
+@@ -1877,14 +1877,14 @@
+ 
+   // The FPU stack is clean if UseSSE >= 2 but must be cleaned in other cases
+   if (UseSSE < 2) {
+-    __ lea(state, Address(rbp,  -sizeof(BytecodeInterpreter)));
++    __ lea(state, Address(rbp,  -(int)sizeof(BytecodeInterpreter)));
+     __ movptr(rbx, STATE(_result._to_call._callee));                   // get method just executed
+     __ movl(rcx, Address(rbx, methodOopDesc::result_index_offset()));
+     __ cmpl(rcx, AbstractInterpreter::BasicType_as_index(T_FLOAT));    // Result stub address array index
+     __ jcc(Assembler::equal, do_float);
+     __ cmpl(rcx, AbstractInterpreter::BasicType_as_index(T_DOUBLE));    // Result stub address array index
+     __ jcc(Assembler::equal, do_double);
+-#ifdef COMPILER2
++#if !defined(_LP64) || defined(COMPILER1) || !defined(COMPILER2)
+     __ empty_FPU_stack();
+ #endif // COMPILER2
+     __ jmp(done_conv);
+@@ -1928,7 +1928,7 @@
+ 
+   // Restore rsi/r13 as compiled code may not preserve it
+ 
+-  __ lea(state, Address(rbp,  -sizeof(BytecodeInterpreter)));
++  __ lea(state, Address(rbp,  -(int)sizeof(BytecodeInterpreter)));
+ 
+   // restore stack to what we had when we left (in case i2c extended it)
+ 
+@@ -1942,7 +1942,7 @@
+ #else
+   __ movptr(rcx, STATE(_thread));                       // get thread
+   __ cmpptr(Address(rcx, Thread::pending_exception_offset()), (int32_t)NULL_WORD);
+-#endif / __LP64
++#endif // _LP64
+   __ jcc(Assembler::notZero, return_with_exception);
+ 
+   // get method just executed
+--- openjdk/hotspot/src/cpu/x86/vm/frame_x86.inline.hpp.orig	2009-01-13 10:15:42.000000000 +0000
++++ openjdk/hotspot/src/cpu/x86/vm/frame_x86.inline.hpp	2009-01-13 10:17:05.000000000 +0000
+@@ -139,7 +139,7 @@
+ #ifdef CC_INTERP
+ 
+ inline interpreterState frame::get_interpreterState() const {
+-  return ((interpreterState)addr_at( -sizeof(BytecodeInterpreter)/wordSize ));
++  return ((interpreterState)addr_at( -((int)sizeof(BytecodeInterpreter))/wordSize ));
+ }
+ 
+ inline intptr_t*    frame::sender_sp()        const {
+--- openjdk/hotspot/src/cpu/x86/vm/assembler_x86.cpp.orig	2009-01-13 10:15:42.000000000 +0000
++++ openjdk/hotspot/src/cpu/x86/vm/assembler_x86.cpp	2009-01-13 10:17:05.000000000 +0000
+@@ -6943,29 +6943,32 @@
+ 
+   Label slow_case, done;
+ 
+-  // x ?<= pi/4
+-  fld_d(ExternalAddress((address)&pi_4));
+-  fld_s(1);                // Stack:  X  PI/4  X
+-  fabs();                  // Stack: |X| PI/4  X
+-  fcmp(tmp);
+-  jcc(Assembler::above, slow_case);
+-
+-  // fastest case: -pi/4 <= x <= pi/4
+-  switch(trig) {
+-  case 's':
+-    fsin();
+-    break;
+-  case 'c':
+-    fcos();
+-    break;
+-  case 't':
+-    ftan();
+-    break;
+-  default:
+-    assert(false, "bad intrinsic");
+-    break;
++  ExternalAddress pi4_adr = (address)&pi_4;
++  if (reachable(pi4_adr)) {
++    // x ?<= pi/4
++    fld_d(pi4_adr); // ExternalAddress((address)&pi_4));
++    fld_s(1);                // Stack:  X  PI/4  X
++    fabs();                  // Stack: |X| PI/4  X
++    fcmp(tmp);
++    jcc(Assembler::above, slow_case);
++
++    // fastest case: -pi/4 <= x <= pi/4
++    switch(trig) {
++    case 's':
++      fsin();
++      break;
++    case 'c':
++      fcos();
++      break;
++    case 't':
++      ftan();
++      break;
++    default:
++      assert(false, "bad intrinsic");
++      break;
++    }
++    jmp(done);
+   }
+-  jmp(done);
+ 
+   // slow case: runtime call
+   bind(slow_case);
+--- openjdk/hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp.orig	2009-01-13 10:15:42.000000000 +0000
++++ openjdk/hotspot/src/cpu/x86/vm/sharedRuntime_x86_64.cpp	2009-01-13 10:17:05.000000000 +0000
+@@ -2954,10 +2954,16 @@
+   __ pushptr(Address(rcx, 0));     // Save return address
+   __ enter();                      // Save old & set new rbp
+   __ subptr(rsp, rbx);             // Prolog
++#ifdef CC_INTERP
++  __ movptr(Address(rbp,
++                  -(sizeof(BytecodeInterpreter)) + in_bytes(byte_offset_of(BytecodeInterpreter, _sender_sp))),
++            sender_sp); // Make it walkable
++#else // CC_INTERP
+   __ movptr(Address(rbp, frame::interpreter_frame_sender_sp_offset * wordSize),
+             sender_sp);            // Make it walkable
+   // This value is corrected by layout_activation_impl
+   __ movptr(Address(rbp, frame::interpreter_frame_last_sp_offset * wordSize), (int32_t)NULL_WORD );
++#endif // CC_INTERP
+   __ mov(sender_sp, rsp);          // Pass sender_sp to next frame
+   __ addptr(rsi, wordSize);        // Bump array pointer (sizes)
+   __ addptr(rcx, wordSize);        // Bump array pointer (pcs)
+--- openjdk/hotspot/src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp.orig	2009-01-13 10:15:42.000000000 +0000
++++ openjdk/hotspot/src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp	2009-01-13 10:17:05.000000000 +0000
+@@ -213,7 +213,7 @@
+ 
+ inline jint BytecodeInterpreter::VMintDiv(jint op1, jint op2) {
+   /* it's possible we could catch this special case implicitly */
+-  if (op1 == 0x80000000 && op2 == -1) return op1;
++  if ((juint)op1 == 0x80000000 && op2 == -1) return op1;
+   else return op1 / op2;
+ }
+ 
+@@ -231,7 +231,7 @@
+ 
+ inline jint BytecodeInterpreter::VMintRem(jint op1, jint op2) {
+   /* it's possible we could catch this special case implicitly */
+-  if (op1 == 0x80000000 && op2 == -1) return 0;
++  if ((juint)op1 == 0x80000000 && op2 == -1) return 0;
+   else return op1 % op2;
+ }
+ 
+--- openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.cpp.orig	2009-01-13 10:15:42.000000000 +0000
++++ openjdk/hotspot/src/cpu/x86/vm/interp_masm_x86_64.cpp	2009-01-13 10:17:05.000000000 +0000
+@@ -30,7 +30,7 @@
+ 
+ #ifdef CC_INTERP
+ void InterpreterMacroAssembler::get_method(Register reg) {
+-  movptr(reg, Address(rbp, -(sizeof(BytecodeInterpreter) + 2 * wordSize)));
++  movptr(reg, Address(rbp, -((int)sizeof(BytecodeInterpreter) + 2 * wordSize)));
+   movptr(reg, Address(reg, byte_offset_of(BytecodeInterpreter, _method)));
+ }
+ #endif // CC_INTERP
+--- openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp.orig	2009-01-13 10:16:45.000000000 +0000
++++ openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp	2009-01-13 10:17:05.000000000 +0000
+@@ -163,7 +163,7 @@
+ #ifdef USELABELS
+ // Have to do this dispatch this way in C++ because otherwise gcc complains about crossing an
+ // initialization (which is is the initialization of the table pointer...)
+-#define DISPATCH(opcode) goto *dispatch_table[opcode]
++#define DISPATCH(opcode) goto *(void*)dispatch_table[opcode]
+ #define CONTINUE {                              \
+         opcode = *pc;                           \
+         DO_UPDATE_INSTRUCTION_COUNT(opcode);    \
+@@ -341,7 +341,7 @@
+  */
+ #undef CHECK_NULL
+ #define CHECK_NULL(obj_)                                                 \
+-    if ((obj_) == 0) {                                                   \
++    if ((obj_) == NULL) {                                                \
+         VM_JAVA_ERROR(vmSymbols::java_lang_NullPointerException(), "");  \
+     }
+ 
+@@ -1362,7 +1362,7 @@
+ 
+ #define NULL_COMPARISON_NOT_OP(name)                                         \
+       CASE(_if##name): {                                                     \
+-          int skip = (!(STACK_OBJECT(-1) == 0))                              \
++          int skip = (!(STACK_OBJECT(-1) == NULL))                           \
+                       ? (int16_t)Bytes::get_Java_u2(pc + 1) : 3;             \
+           address branch_pc = pc;                                            \
+           UPDATE_PC_AND_TOS(skip, -1);                                       \
+@@ -1372,7 +1372,7 @@
+ 
+ #define NULL_COMPARISON_OP(name)                                             \
+       CASE(_if##name): {                                                     \
+-          int skip = ((STACK_OBJECT(-1) == 0))                               \
++          int skip = ((STACK_OBJECT(-1) == NULL))                            \
+                       ? (int16_t)Bytes::get_Java_u2(pc + 1) : 3;             \
+           address branch_pc = pc;                                            \
+           UPDATE_PC_AND_TOS(skip, -1);                                       \
+--- openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.hpp.orig	2009-01-13 10:15:42.000000000 +0000
++++ openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.hpp	2009-01-13 10:17:05.000000000 +0000
+@@ -66,7 +66,6 @@
+ friend class InterpreterGenerator;
+ friend class InterpreterMacroAssembler;
+ friend class frame;
+-friend class SharedRuntime;
+ friend class VMStructs;
+ 
+ public:
diff -r e34ba0ba2281 -r c672bd2ca978 patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch
--- a/patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch	Mon Jan 12 17:29:21 2009 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,11 +0,0 @@
---- openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp.old	2009-01-06 16:16:57.000000000 -0700
-+++ openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp	2009-01-06 16:17:53.000000000 -0700
-@@ -163,7 +163,7 @@
- #ifdef USELABELS
- // Have to do this dispatch this way in C++ because otherwise gcc complains about crossing an
- // initialization (which is is the initialization of the table pointer...)
--#define DISPATCH(opcode) goto *dispatch_table[opcode]
-+#define DISPATCH(opcode) goto *(void *)dispatch_table[opcode]
- #define CONTINUE {                              \
-         opcode = *pc;                           \
-         DO_UPDATE_INSTRUCTION_COUNT(opcode);    \
diff -r e34ba0ba2281 -r c672bd2ca978 patches/hotspot/14.0b08/icedtea-includedb.patch
--- a/patches/hotspot/14.0b08/icedtea-includedb.patch	Mon Jan 12 17:29:21 2009 +0000
+++ b/patches/hotspot/14.0b08/icedtea-includedb.patch	Tue Jan 13 12:30:34 2009 +0100
@@ -1,10 +1,97 @@
---- openjdk/hotspot/src/share/vm/includeDB_core.orig	2008-11-21 17:11:18.000000000 -0700
-+++ openjdk/hotspot/src/share/vm/includeDB_core	2009-01-08 14:32:58.000000000 -0700
-@@ -1314,6 +1314,7 @@
- cppInterpreter_<arch>.cpp               interpreterRuntime.hpp
- cppInterpreter_<arch>.cpp               interpreter.hpp
- cppInterpreter_<arch>.cpp               interpreterGenerator.hpp
-+cppInterpreter_<arch>.cpp               interfaceSupport.hpp
- cppInterpreter_<arch>.cpp               jvmtiExport.hpp
- cppInterpreter_<arch>.cpp               jvmtiThreadState.hpp
- cppInterpreter_<arch>.cpp               methodDataOop.hpp
+--- openjdk/hotspot/src/share/vm/includeDB_compiler2.orig	2009-01-13 10:10:44.000000000 +0000
++++ openjdk/hotspot/src/share/vm/includeDB_compiler2	2009-01-13 10:11:17.000000000 +0000
+@@ -140,6 +140,7 @@
+ c2_globals_<os_family>.hpp              macros.hpp
+ 
+ c2_init_<arch>.cpp                      compile.hpp
++c2_init_<arch>.cpp                      node.hpp
+ 
+ c2compiler.cpp                          ad_<arch_model>.hpp
+ c2compiler.cpp                          c2compiler.hpp
+@@ -839,6 +840,7 @@
+ phase.cpp                               compile.hpp
+ phase.cpp                               compileBroker.hpp
+ phase.cpp                               nmethod.hpp
++phase.cpp                               node.hpp
+ phase.cpp                               phase.hpp
+ 
+ phase.hpp                               port.hpp
+--- openjdk/hotspot/src/share/vm/gc_implementation/includeDB_gc_g1.orig	2009-01-13 10:10:44.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/includeDB_gc_g1	2009-01-13 10:11:17.000000000 +0000
+@@ -34,6 +34,7 @@
+ collectionSetChooser.cpp		g1CollectedHeap.hpp
+ collectionSetChooser.cpp		g1CollectorPolicy.hpp
+ collectionSetChooser.cpp		collectionSetChooser.hpp
++collectionSetChooser.cpp		space.inline.hpp
+ 
+ collectionSetChooser.hpp		heapRegion.hpp
+ collectionSetChooser.hpp                growableArray.hpp
+@@ -44,6 +45,7 @@
+ concurrentG1Refine.cpp			copy.hpp
+ concurrentG1Refine.cpp			g1CollectedHeap.hpp
+ concurrentG1Refine.cpp			g1RemSet.hpp
++concurrentG1Refine.cpp			space.inline.hpp
+ 
+ concurrentG1Refine.hpp			globalDefinitions.hpp
+ 
+@@ -264,7 +266,7 @@
+ heapRegion.cpp                          iterator.hpp
+ heapRegion.cpp                          oop.inline.hpp
+ 
+-heapRegion.hpp                          space.hpp
++heapRegion.hpp                          space.inline.hpp
+ heapRegion.hpp                          spaceDecorator.hpp
+ heapRegion.hpp                          g1BlockOffsetTable.inline.hpp
+ heapRegion.hpp                          watermark.hpp
+--- openjdk/hotspot/src/share/vm/gc_implementation/includeDB_gc_parallelScavenge.orig	2009-01-13 10:10:44.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/includeDB_gc_parallelScavenge	2009-01-13 10:11:17.000000000 +0000
+@@ -306,6 +306,8 @@
+ psPermGen.cpp                           psMarkSweepDecorator.hpp
+ psPermGen.cpp                           psParallelCompact.hpp
+ psPermGen.cpp                           psPermGen.hpp
++psPermGen.cpp                           markOop.inline.hpp
++psPermGen.cpp                           markSweep.inline.hpp
+ 
+ psPermGen.hpp                           psOldGen.hpp
+ 
+--- openjdk/hotspot/src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep.orig	2009-01-13 10:10:44.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep	2009-01-13 10:11:17.000000000 +0000
+@@ -28,6 +28,7 @@
+ binaryTreeDictionary.cpp                binaryTreeDictionary.hpp
+ binaryTreeDictionary.cpp                globals.hpp
+ binaryTreeDictionary.cpp                ostream.hpp
++binaryTreeDictionary.cpp                space.inline.hpp
+ binaryTreeDictionary.cpp                spaceDecorator.hpp
+ 
+ binaryTreeDictionary.hpp                freeBlockDictionary.hpp
+--- openjdk/hotspot/src/share/vm/gc_implementation/includeDB_gc_parNew.orig	2009-01-13 10:10:44.000000000 +0000
++++ openjdk/hotspot/src/share/vm/gc_implementation/includeDB_gc_parNew	2009-01-13 10:11:17.000000000 +0000
+@@ -29,6 +29,8 @@
+ asParNewGeneration.cpp                  cmsAdaptiveSizePolicy.hpp
+ asParNewGeneration.cpp                  cmsGCAdaptivePolicyCounters.hpp
+ asParNewGeneration.cpp                  defNewGeneration.inline.hpp
++asParNewGeneration.cpp                  markOop.inline.hpp
++asParNewGeneration.cpp                  markSweep.inline.hpp
+ asParNewGeneration.cpp                  oop.pcgc.inline.hpp
+ asParNewGeneration.cpp                  parNewGeneration.hpp
+ asParNewGeneration.cpp                  referencePolicy.hpp
+@@ -40,7 +42,7 @@
+ parCardTableModRefBS.cpp                java.hpp
+ parCardTableModRefBS.cpp                mutexLocker.hpp
+ parCardTableModRefBS.cpp                sharedHeap.hpp
+-parCardTableModRefBS.cpp                space.hpp
++parCardTableModRefBS.cpp                space.inline.hpp
+ parCardTableModRefBS.cpp                universe.hpp
+ parCardTableModRefBS.cpp                virtualspace.hpp
+ 
+--- openjdk/hotspot/src/share/vm/includeDB_features.orig	2009-01-13 10:10:44.000000000 +0000
++++ openjdk/hotspot/src/share/vm/includeDB_features	2009-01-13 10:11:17.000000000 +0000
+@@ -59,6 +59,8 @@
+ 
+ dump_<arch_model>.cpp                   assembler_<arch>.inline.hpp
+ dump_<arch_model>.cpp                   compactingPermGenGen.hpp
++dump_<arch_model>.cpp                   generation.inline.hpp
++dump_<arch_model>.cpp                   space.inline.hpp
+ 
+ forte.cpp                               collectedHeap.inline.hpp
+ forte.cpp                               debugInfoRec.hpp


From doko at ubuntu.com  Tue Jan 13 04:14:28 2009
From: doko at ubuntu.com (Matthias Klose)
Date: Tue, 13 Jan 2009 13:14:28 +0100
Subject: source files java/* and javax/* missing in src.zip 
Message-ID: <496C85A4.4050000@ubuntu.com>

This was reported in the Debian bug tracker as #504568. The src.zip only has
com/sun files included. Is this intended?

  Matthias


From mark at klomp.org  Tue Jan 13 04:42:17 2009
From: mark at klomp.org (Mark Wielaard)
Date: Tue, 13 Jan 2009 13:42:17 +0100
Subject: source files java/* and javax/* missing in src.zip
In-Reply-To: <496C85A4.4050000@ubuntu.com>
References: <496C85A4.4050000@ubuntu.com>
Message-ID: <1231850537.2330.273.camel@localhost.localdomain>

Hi Matthias,

On Tue, 2009-01-13 at 13:14 +0100, Matthias Klose wrote:
> This was reported in the Debian bug tracker as #504568. The src.zip only has
> com/sun files included. Is this intended?

That must be some build bug. Maybe a find or tar issue? Look in
openjdk/jdk/make/common/Release.gmk for the logic to create the src.zip,
that has some comments about the expected behavior of tar and find. Note
that patches/icedtea-sunsrc.patch makes sure that also sources starting
with sun/ are included, maybe that patch is applied wrongly?

My freshly (well, yesterday) build of icedtea6 contains a src.zip
containing all source files (com, com.sun, java, javax, launcher, org,
sun and sunw) in openjdk/control/build/linux-amd64/j2sdk-image/src.zip
(27M).

Cheers,

Mark



From gbenson at redhat.com  Tue Jan 13 05:31:34 2009
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 13 Jan 2009 13:31:34 +0000
Subject: changeset in /hg/icedtea6: 2009-01-13  Gary Benson  <gbenson@red...
Message-ID: <hg.fe32914531b8.1231853494.2873452341184383832@icedtea.classpath.org>

changeset fe32914531b8 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=fe32914531b8
description:
	2009-01-13  Gary Benson  <gbenson at redhat.com>

		* contrib/jck/compile-native-code.sh: Build with -m32 or -m64.

diffstat:

2 files changed, 23 insertions(+), 6 deletions(-)
ChangeLog                          |    4 ++++
contrib/jck/compile-native-code.sh |   25 +++++++++++++++++++------

diffs (72 lines):

diff -r c672bd2ca978 -r fe32914531b8 ChangeLog
--- a/ChangeLog	Tue Jan 13 12:30:34 2009 +0100
+++ b/ChangeLog	Tue Jan 13 08:30:52 2009 -0500
@@ -1,3 +1,7 @@ 2009-01-13  Matthias Klose  <doko at ubuntu
+2009-01-13  Gary Benson  <gbenson at redhat.com>
+
+	* contrib/jck/compile-native-code.sh: Build with -m32 or -m64.
+
 2009-01-13  Matthias Klose  <doko at ubuntu.com>
 
 	* patches/hotspot/14.0b08/icedtea-hotspot-dispatch.patch: Remove,
diff -r c672bd2ca978 -r fe32914531b8 contrib/jck/compile-native-code.sh
--- a/contrib/jck/compile-native-code.sh	Tue Jan 13 12:30:34 2009 +0100
+++ b/contrib/jck/compile-native-code.sh	Tue Jan 13 08:30:52 2009 -0500
@@ -17,6 +17,19 @@ if [ -z $basedir ]; then
   exit 1
 fi
 
+arch=$(uname -m)
+case "$arch" in
+  i?86|ppc)
+    MFLAG=-m32
+    ;;
+  x86_64|ppc64)
+    MFLAG=-m64
+    ;;
+  *)
+    echo 1>&2 "error: unhandled arch '$arch'"
+    exit 1
+esac
+
 LIBDIR=$basedir/lib
 RESDIR=$basedir/resources
 
@@ -29,31 +42,31 @@ cp -r $JCKDIR/tests/api/javax_management
 cp -r $JCKDIR/tests/api/javax_management/loading/data/* $RESDIR
 chmod -R +w  $RESDIR
 
-gcc -fPIC -shared -o $LIBDIR/libjckatr.so -I$JCKDIR \
+gcc $MFLAG -fPIC -shared -o $LIBDIR/libjckatr.so -I$JCKDIR \
   $JCKDIR/src/share/lib/atr/jckatr.c   
 
-gcc -fPIC -shared -o $LIBDIR/libjckjni.so -I$JCKDIR \
+gcc $MFLAG -fPIC -shared -o $LIBDIR/libjckjni.so -I$JCKDIR \
   -I$JCKDIR/src/share/lib/jni/include \
   -I$JCKDIR/src/share/lib/jni/include/solaris \
   $JCKDIR/src/share/lib/jni/jckjni.c   
 
-gcc -fPIC -shared -o $LIBDIR/libjckjvmti.so -I$JCKDIR \
+gcc $MFLAG -fPIC -shared -o $LIBDIR/libjckjvmti.so -I$JCKDIR \
   -I$JCKDIR/src/share/lib/jvmti/include \
   -I$JCKDIR/src/share/lib/jni/include \
   -I$JCKDIR/src/share/lib/jni/include/solaris \
   $JCKDIR/src/share/lib/jvmti/jckjvmti.c   
 
-gcc -fPIC -shared -o $LIBDIR/libsystemInfo.so \
+gcc $MFLAG -fPIC -shared -o $LIBDIR/libsystemInfo.so \
   -I$JCKDIR/src/share/lib/jni/include \
   -I$JCKDIR/src/share/lib/jni/include/solaris \
   $JCKDIR/tests/api/javax_management/loading/data/archives/src/C/com_sun_management_mbeans_loading_SystemInfoUseNativeLib.c   
 
-gcc -fPIC -shared -o $LIBDIR/libjmxlibid.so \
+gcc $MFLAG -fPIC -shared -o $LIBDIR/libjmxlibid.so \
   -I$JCKDIR/src/share/lib/jni/include \
   -I$JCKDIR/src/share/lib/jni/include/solaris \
   $JCKDIR/tests/api/javax_management/loading/data/archives/src/C/com_sun_management_mbeans_loading_GetLibIdFromNativeLib.c   
 
-gcc -fPIC -shared -o $LIBDIR/libgenrandom.so \
+gcc $MFLAG -fPIC -shared -o $LIBDIR/libgenrandom.so \
   -I$JCKDIR/src/share/lib/jni/include \
   -I$JCKDIR/src/share/lib/jni/include/solaris \
   $JCKDIR/tests/api/javax_management/loading/data/archives/src/C/com_sun_management_mbeans_loading_RandomGen.c   


From gbenson at redhat.com  Tue Jan 13 08:23:38 2009
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 13 Jan 2009 16:23:38 +0000
Subject: Shark: fix ldc(Class)
In-Reply-To: <496C6FC0.8020609@redhat.com>
References: <496B7E5D.9090600@redhat.com> <20090113082552.GA3588@redhat.com>
	<496C6465.5080402@redhat.com> <20090113100550.GD3588@redhat.com>
	<496C6FC0.8020609@redhat.com>
Message-ID: <20090113162338.GF3588@redhat.com>

Andrew Haley wrote:
> Gary Benson wrote:
> > Andrew Haley wrote:
> > > Incidentally, I think there has to me a memory barrier between
> > > reading the tag and reading the constant pool entry.  The c++
> > > interpeter does this by calling byte_at_acquire().
> > 
> > A lot of those OrderAccess functions are barrierless on every
> > platform:
> > 
> >  hotspot/src/share/vm/oops/constantPoolOop.hpp: constantTag tag_at(int which) const { return (constantTag) tags()->byte_at_acquire(which); }
> >   ...
> >  hotspot/src/share/vm/oops/typeArrayOop.hpp: jbyte byte_at_acquire(int which) const { return OrderAccess::load_acquire(byte_at_addr(which)); }
> >   ...
> >  hotspot/src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
> >  hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp:         inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
> >  hotspot/src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp: inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
> >  hotspot/src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
> >  hotspot/src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp:     inline jbyte OrderAccess::load_acquire(volatile jbyte* p) { return *p; }
> > 
> > I just did the same for Zero.  It seemed hacky, but I wasn't sure
> > what else to do...
> 
> Many of the CPUs we use won't be affected.  SPARC apparently can use
> either Total Store ordering (TSO) or Partial Store Order (PSO) or
> Relaxed Memory Order (RMO).  :-)
> 
> http://developers.sun.com/solaris/articles/atomic_sparc/
> 
> From what you say, I think the Java VM assumes TSO.
> 
> TSO is, approximately, what we have on x86_64 too.
> 
> PowerPC uses, as far as I can see, Relaxed Store Ordering.
> So, Load Acquire requires a sync.
[snip]

That's... unpleasant.  Changing Zero ought not to be too difficult;
orderAccess_linux_zero.inline.hpp has acquire() and release()
functions defined, right at the top, so presumably load_acquire et al
just need conditionalized calls to these inserting.  Shark on the
other hand... there will be other places in Shark aside from the one
you mentioned where I've inlined OrderAccess calls as simple loads and
stores.  There may not be any way around this other than an audit.

I filed http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=282
about this so it doesn't get lost.

Cheers,
Gary

-- 
http://gbenson.net/


From bugzilla-daemon at icedtea.classpath.org  Tue Jan 13 10:26:47 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 13 Jan 2009 18:26:47 +0000
Subject: [Bug 197] Java2D: Dash array does not work in java.awt.BasicStroke
Message-ID: <E1LMnyR-00058s-UD@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197


omajid at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From bugzilla-daemon at icedtea.classpath.org  Tue Jan 13 10:43:09 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Tue, 13 Jan 2009 18:43:09 +0000
Subject: [Bug 197] Java2D: Dash array does not work in java.awt.BasicStroke
Message-ID: <E1LMoEH-0005AJ-E9@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=197


omajid at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at icedtea.classpath|omajid at redhat.com
                   |.org                        |
             Status|ASSIGNED                    |NEW




-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the assignee for the bug, or are watching the assignee.


From mvfranz at gmail.com  Tue Jan 13 16:22:46 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Tue, 13 Jan 2009 19:22:46 -0500
Subject: IcedTea Bootstrap Process
Message-ID: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>

Hi,

I have been trying to find documentation on how the bootstrap build works on
IcedTea, but have not found it.  I have tried to read the Makefile, but I
must admit I am not that proficient with makefiles.

If there is no documentation, perhaps answers to these question will help
me.

1. How many passes (full compilations) are there done on the source before
the final jdk is complete?
2. How much (if any) of the source that is being built is compiled and put
into the rt-closed.jar?
3. Is rt-closed.jar all that should be needed to compile the JDK the first
time?
4. What is the expected results of a successful bootstrap?

Thanks

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090113/566717fc/attachment.html 

From omajid at redhat.com  Tue Jan 13 19:28:43 2009
From: omajid at redhat.com (Omair Majid)
Date: Wed, 14 Jan 2009 03:28:43 +0000
Subject: changeset in /hg/icedtea6: 2009-01-13  Omair Majid  <omajid@redh...
Message-ID: <hg.3b8609a88eaf.1231903723.2873452341184383832@icedtea.classpath.org>

changeset 3b8609a88eaf in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=3b8609a88eaf
description:
	2009-01-13  Omair Majid  <omajid at redhat.com>

	    * rt/net/sourceforge/jnlp/cache/ResourceTracker.java
	    (downloadResource): Call getVersionedResourceURL to get the versioned jar.
	    (initializeResource): Likewise.
	    (getVersionedResourceURL): New function. Constructs a URL with a
	    version-id as the query.

diffstat:

2 files changed, 33 insertions(+), 2 deletions(-)
ChangeLog                                          |    8 +++++
rt/net/sourceforge/jnlp/cache/ResourceTracker.java |   27 ++++++++++++++++++--

diffs (66 lines):

diff -r fe32914531b8 -r 3b8609a88eaf ChangeLog
--- a/ChangeLog	Tue Jan 13 08:30:52 2009 -0500
+++ b/ChangeLog	Tue Jan 13 22:27:58 2009 -0500
@@ -1,3 +1,11 @@ 2009-01-13  Gary Benson  <gbenson at redhat
+2009-01-13  Omair Majid  <omajid at redhat.com>
+
+	* rt/net/sourceforge/jnlp/cache/ResourceTracker.java
+	(downloadResource): Call getVersionedResourceURL to get the versioned jar.
+	(initializeResource): Likewise.
+	(getVersionedResourceURL): New function. Constructs a URL with a
+	version-id as the query.
+
 2009-01-13  Gary Benson  <gbenson at redhat.com>
 
 	* contrib/jck/compile-native-code.sh: Build with -m32 or -m64.
diff -r fe32914531b8 -r 3b8609a88eaf rt/net/sourceforge/jnlp/cache/ResourceTracker.java
--- a/rt/net/sourceforge/jnlp/cache/ResourceTracker.java	Tue Jan 13 08:30:52 2009 -0500
+++ b/rt/net/sourceforge/jnlp/cache/ResourceTracker.java	Tue Jan 13 22:27:58 2009 -0500
@@ -605,7 +605,7 @@ public class ResourceTracker {
 
         try {
             // create out second in case in does not exist
-            URLConnection con = resource.location.openConnection();
+            URLConnection con = getVersionedResourceURL(resource).openConnection();
             InputStream in = new BufferedInputStream(con.getInputStream());
             OutputStream out = CacheUtil.getOutputStream(resource.location, resource.downloadVersion);
             byte buf[] = new byte[1024];
@@ -652,7 +652,7 @@ public class ResourceTracker {
             File localFile = CacheUtil.getCacheFile(resource.location, resource.downloadVersion);
 
             // connect
-            URLConnection connection = resource.location.openConnection(); // this won't change so should be okay unsynchronized
+            URLConnection connection = getVersionedResourceURL(resource).openConnection(); // this won't change so should be okay unsynchronized
             int size = connection.getContentLength();
             boolean current = CacheUtil.isCurrent(resource.location, resource.requestVersion, connection) && resource.getUpdatePolicy() != UpdatePolicy.FORCE;
 
@@ -696,6 +696,29 @@ public class ResourceTracker {
         }
     }
 
+    
+ 
+    private URL getVersionedResourceURL(Resource resource) {
+        String actualLocation = resource.location.getProtocol() + "://"
+                + resource.location.getHost();
+        if (resource.location.getPort() != -1) {
+            actualLocation += ":" + resource.location.getPort();
+        }
+        actualLocation += resource.location.getPath();
+        if (resource.requestVersion != null
+                && resource.requestVersion.isVersionId()) {
+            actualLocation += "?version-id=" + resource.requestVersion;
+        }
+        URL versionedURL;
+        try {
+            versionedURL = new URL(actualLocation);
+        } catch (MalformedURLException e) {
+            return resource.location;
+        }
+        return versionedURL;
+    }
+ 
+    
     /**
      * Pick the next resource to download or initialize.  If there
      * are no more resources requested then one is taken from a


From bugzilla-daemon at icedtea.classpath.org  Tue Jan 13 20:11:49 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Wed, 14 Jan 2009 04:11:49 +0000
Subject: [Bug 255] label display in swing ui elements needs (inappropriate)
	additional vertical space
Message-ID: <E1LMx6b-0005YB-WE@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=255





------- Comment #5 from omajid at redhat.com  2009-01-14 04:11 -------
(In reply to comment #4)
> ok (with sun java)
>     http://launchpadlibrarian.net/18497525/vertically-centered.png
> 
> rechecked (wrong) with openjdk by bug submitter:
>     http://launchpadlibrarian.net/18556877/iso--8859-15-large-borders.png
> 

This particular bug is due to a mistake in the calculation of a window size.
The button then expands to fill the entire window. It has been fixed in
icedtea6 head:
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-January/004455.html.
The rest of the bugs pointed out on the launchpad page seem unrelated to this
one.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From gnu_andrew at member.fsf.org  Tue Jan 13 20:35:12 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 14 Jan 2009 04:35:12 +0000
Subject: IcedTea Bootstrap Process
In-Reply-To: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>
Message-ID: <17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>

2009/1/14 Michael Franz <mvfranz at gmail.com>:
> Hi,
>
> I have been trying to find documentation on how the bootstrap build works on
> IcedTea, but have not found it.  I have tried to read the Makefile, but I
> must admit I am not that proficient with makefiles.
>

That would be a little difficult, given most of the makefiles are part
of the OpenJDK build which is downloaded by IcedTea i.e. if you're
looking at just what comes from a Mercurial checkout or a tarball,
it'll not make a lot of sense...

> If there is no documentation, perhaps answers to these question will help
> me.

If you couldn't find any, what there is is too well hidden...

>
> 1. How many passes (full compilations) are there done on the source before
> the final jdk is complete?

By default, 2.  OpenJDK is built once with the system JDK.  This is
assumed to be gcj/ecj or some other GNU Classpath variant as these are
the only Free options other than IcedTea/OpenJDK itself (saying that,
I suppose there is Harmony but I don't know of anyone trying to build
with that and whether that also needs a JDK to build too).  This
applies some additional patches (located in patches/ecj) which disable
a few things, remove some Sun-specific assumptions, etc.  Sorry to be
a bit vague, but we probably do need to go through the patch to see
what's in there and what's still needed.

The built JDK is then tested by being used to build OpenJDK.  If you
already have IcedTea (say from your distro), you can skip straight to
this stage using --with-icedtea and --with-icedtea-home to specify a
path to your existing IcedTea installation if the default is no good
(these two options should be combined IMO).  The system IcedTea needs
to be fairly new as some IcedTea plugin stuff is assumed to be
presented AFAIR.

The alternate builds (zero assembler, shark, cacao) follow the same
process; their alterations primarily affect HotSpot.

> 2. How much (if any) of the source that is being built is compiled and put
> into the rt-closed.jar?

An ecj step before the OpenJDK build compiles enough of the OpenJDK
sources separately to satisfy the OpenJDK build.  The OpenJDK build is
designed only for Sun JDKs it seems, and so relies on a lot of
Sun-specific classes being present in the build JDK (far over and
above what's in the spec.).  These are added to rt-closed.jar (the
naming is from the OpenJDK build assuming this is an existing
proprietary JDK IIRC).  What is included has been found by trial and
error.  For instance, javax/script was recently added to the list as
it's needed by newer versions of HotSpot.  The list can be found as
ICEDTEA_COPY_DIRS in Makefile.am:

# Sources copied from OpenJDK.
ICEDTEA_COPY_DIRS = \
        com/sun/jdi \
        com/sun/jdi/connect \
        com/sun/jdi/connect/spi \
        com/sun/jdi/event \
        com/sun/jdi/request \
        com/sun/jmx/snmp/agent \
        com/sun/tools/jdi \
        java/io \
	java/util \
	java/rmi \
        sun/awt/ \
        javax/net/ssl

if WITH_ALT_HSBUILD
ICEDTEA_COPY_DIRS += \
        javax/script
endif

This is from IcedTea6.  Note that the SNMP stuff is stubbed, and
should probably just be removed and IMPORT_BINARY_PLUGS=false set on
the OpenJDK build.

> 3. Is rt-closed.jar all that should be needed to compile the JDK the first
> time?

Yes, as explained above.

> 4. What is the expected results of a successful bootstrap?

A fully-compliant 1.6 JDK? :)
You should get:

IcedTea is served.

when you reach the end.  The results are in
openjdk/control/build/${OS}-${ARCH}/j2sdk-image (omit the 'control'
segment on IcedTea7).

The easiest way to try a pain-free build is to try it on Fedora where
it should just ./configure and make.

>
> Thanks
>
> Michael
>
>

Thanks,
-- 
Andrew :-)

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


From Jonathan.Gibbons at Sun.COM  Wed Jan 14 13:38:12 2009
From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons)
Date: Wed, 14 Jan 2009 13:38:12 -0800
Subject: Allowing partial jtreg samejvm safe runs
In-Reply-To: <1227460674.29485.26.camel@hermans.wildebeest.org>
References: <1227460674.29485.26.camel@hermans.wildebeest.org>
Message-ID: <496E5B44.2090208@sun.com>

Mark,

Thanks for the idea behind this patch, and for the patch too.

To you and other jtreg users,

I'd be interested in comments regarding the relative merits of
white-listing vs black-listing.  

I'd also be interested in comments regarding the feature of
only using the whitelist when running the whole test suite.
An alternative proposal would be to only use the whitelist
in a default mode, where neither -othervm or -samevm is
defined.  Specifying either switch would disable the whitelist
(or blacklist?) lookup.

-- Jon




Mark Wielaard wrote:
> Hi,
>
> Jonathan Gibbons has been extending jtreg so that tests can be run in
> the same vm. He also made it so that most langtools tests are run that
> way. That brings an enormous speed up. Since running all jdk tests takes
> ages it would be great if we could use this same speedup there.
>
> Problem is that -samevm only works if all tests have been adapted to
> behave well (or marked as needing /othervm). So my idea was to add a
> "whitelist mechanism" so you can indicate which (sub)dirs are ready to
> be run with samevm.
>
> Luckily jtreg has mostly been setup for this already. All Actions ask
> their Script whether or not they should be running in an othervm. So we
> hook into that to check the scripts location against a whitelist.
>
> I choose the TEST.ROOT file as the location of the whitelist. Since that
> is also the root of the test suite. I made the code so that the
> whitelist is only used when running the full test suite from the root.
> That way you can still experiment with -samevm or -othervm when running
> subtrees of tests.
>
> Also CCed jdk-regtest at sun.com since that address is mentioned in the
> TEST.ROOT file with an request to contact them if you change anything in
> that file.
>
> Below is the implementation as I checked into icedtea6 (patch also
> attached).
>
> 2008-11-23  Mark Wielaard  <mark at klomp.org>
>
>     * test/jtreg/com/sun/javatest/regtest/Main.java
>     (createParameters): Set same jvm safe dirs when non-null.
>     (getSameJVMSafeDirs): New method that reads samejvmsafe property
>     from TEST.ROOT.
>     (sameJVMSafeDirs): New private field.
>     * test/jtreg/com/sun/javatest/regtest/RegressionParameters.java
>     (SAME_JVM_SAFE_DIRS): New static final field.
>     (load): Read same jvm safe dirs.
>     (save0): Write same jvm safe dirs.
>     (getSameJVMSafeDirs): New method.
>     (setSameJVMSafeDirs): New method.
>     * test/jtreg/com/sun/javatest/regtest/RegressionScript.java
>     (run): Set testDirPath.
>     (isOtherJVM): Take same jvm safe into account.
>     (isSameJVMSafe): New method.
>     (testDirPath): New private field.
>
> For icedtea6 I did a quick scan of the openjdk/jdk/test subdirs and
> listed an initial set that work with -samejvm and added a patch to
> augment the TEST.ROOT file (attached).
>
> 2008-11-23  Mark Wielaard  <mark at klomp.org>
>
>     * patches/icedtea-samejvm-safe.patch: New patch.
>     * Makefile.am (ICEDTEA_PATCHES): Add new patch.
>     (check-jdk): Run jtreg with -samevm.
>     * HACKING: Document new patch.
>
> Comments on the idea and the implementation very appreciated.
>
> With this 'make check-jdk' takes a little bit less than 3 hours on my
> machine now. It was almost 3.5 hours, so it already saves a lot of time.
> But we need to make much more tests work with samevm to bring the total
> test running time down to something an ordinary developer would be
> comfortable with running every day.
>
> We have to see whether or not that is really possible. It seems jdi, rmi
> and awt take up a lot of the time needed to run all tests, and I am not
> sure those tests can be speed up much.
>
> Cheers,
>
> Mark
>   



From ekrichardson at gmail.com  Wed Jan 14 16:27:06 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Wed, 14 Jan 2009 16:27:06 -0800
Subject: IcedTea Bootstrap Process
In-Reply-To: <17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>
	<17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>
Message-ID: <860cb0120901141627m5cf7fdeke99ed7e111113e56@mail.gmail.com>

Andrew,

This is very helpful. The question I have is about patches.

1. Why do so many patches fail?

Is it because the patches target the OpenJDK  and updates to Open JDK break
the icedtea patches?

Should I go ahead and try to make them all resolve?

2. It seems that there are tons of makefile changes and such brewing on the
bsd-ports list that might help us on Mac OS X. What is the mechanism for
these to flow into Icedtea?

3. Are there some simple tasks I can do such as patch diffs or something on
patches that won't apply?

Thanks,
Eric

On Tue, Jan 13, 2009 at 8:35 PM, Andrew John Hughes <
gnu_andrew at member.fsf.org> wrote:

> 2009/1/14 Michael Franz <mvfranz at gmail.com>:
> > Hi,
> >
> > I have been trying to find documentation on how the bootstrap build works
> on
> > IcedTea, but have not found it.  I have tried to read the Makefile, but I
> > must admit I am not that proficient with makefiles.
> >
>
> That would be a little difficult, given most of the makefiles are part
> of the OpenJDK build which is downloaded by IcedTea i.e. if you're
> looking at just what comes from a Mercurial checkout or a tarball,
> it'll not make a lot of sense...
>
> > If there is no documentation, perhaps answers to these question will help
> > me.
>
> If you couldn't find any, what there is is too well hidden...
>
> >
> > 1. How many passes (full compilations) are there done on the source
> before
> > the final jdk is complete?
>
> By default, 2.  OpenJDK is built once with the system JDK.  This is
> assumed to be gcj/ecj or some other GNU Classpath variant as these are
> the only Free options other than IcedTea/OpenJDK itself (saying that,
> I suppose there is Harmony but I don't know of anyone trying to build
> with that and whether that also needs a JDK to build too).  This
> applies some additional patches (located in patches/ecj) which disable
> a few things, remove some Sun-specific assumptions, etc.  Sorry to be
> a bit vague, but we probably do need to go through the patch to see
> what's in there and what's still needed.
>
> The built JDK is then tested by being used to build OpenJDK.  If you
> already have IcedTea (say from your distro), you can skip straight to
> this stage using --with-icedtea and --with-icedtea-home to specify a
> path to your existing IcedTea installation if the default is no good
> (these two options should be combined IMO).  The system IcedTea needs
> to be fairly new as some IcedTea plugin stuff is assumed to be
> presented AFAIR.
>
> The alternate builds (zero assembler, shark, cacao) follow the same
> process; their alterations primarily affect HotSpot.
>
> > 2. How much (if any) of the source that is being built is compiled and
> put
> > into the rt-closed.jar?
>
> An ecj step before the OpenJDK build compiles enough of the OpenJDK
> sources separately to satisfy the OpenJDK build.  The OpenJDK build is
> designed only for Sun JDKs it seems, and so relies on a lot of
> Sun-specific classes being present in the build JDK (far over and
> above what's in the spec.).  These are added to rt-closed.jar (the
> naming is from the OpenJDK build assuming this is an existing
> proprietary JDK IIRC).  What is included has been found by trial and
> error.  For instance, javax/script was recently added to the list as
> it's needed by newer versions of HotSpot.  The list can be found as
> ICEDTEA_COPY_DIRS in Makefile.am:
>
> # Sources copied from OpenJDK.
> ICEDTEA_COPY_DIRS = \
>        com/sun/jdi \
>        com/sun/jdi/connect \
>        com/sun/jdi/connect/spi \
>        com/sun/jdi/event \
>        com/sun/jdi/request \
>        com/sun/jmx/snmp/agent \
>        com/sun/tools/jdi \
>        java/io \
>        java/util \
>        java/rmi \
>        sun/awt/ \
>        javax/net/ssl
>
> if WITH_ALT_HSBUILD
> ICEDTEA_COPY_DIRS += \
>        javax/script
> endif
>
> This is from IcedTea6.  Note that the SNMP stuff is stubbed, and
> should probably just be removed and IMPORT_BINARY_PLUGS=false set on
> the OpenJDK build.
>
> > 3. Is rt-closed.jar all that should be needed to compile the JDK the
> first
> > time?
>
> Yes, as explained above.
>
> > 4. What is the expected results of a successful bootstrap?
>
> A fully-compliant 1.6 JDK? :)
> You should get:
>
> IcedTea is served.
>
> when you reach the end.  The results are in
> openjdk/control/build/${OS}-${ARCH}/j2sdk-image (omit the 'control'
> segment on IcedTea7).
>
> The easiest way to try a pain-free build is to try it on Fedora where
> it should just ./configure and make.
>
> >
> > Thanks
> >
> > Michael
> >
> >
>
> Thanks,
> --
> Andrew :-)
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090114/df8b669e/attachment.html 

From gnu_andrew at member.fsf.org  Wed Jan 14 16:57:04 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 15 Jan 2009 00:57:04 +0000
Subject: IcedTea Bootstrap Process
In-Reply-To: <860cb0120901141627m5cf7fdeke99ed7e111113e56@mail.gmail.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>
	<17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>
	<860cb0120901141627m5cf7fdeke99ed7e111113e56@mail.gmail.com>
Message-ID: <17c6771e0901141657o7d717a52i621c9a0b25f2a666@mail.gmail.com>

2009/1/15 Eric Richardson <ekrichardson at gmail.com>:
> Andrew,
>
> This is very helpful. The question I have is about patches.
>
> 1. Why do so many patches fail?
>
> Is it because the patches target the OpenJDK  and updates to Open JDK break
> the icedtea patches?
>
> Should I go ahead and try to make them all resolve?

Yes, and also because the BSD tree will have its own changes.

>
> 2. It seems that there are tons of makefile changes and such brewing on the
> bsd-ports list that might help us on Mac OS X. What is the mechanism for
> these to flow into Icedtea?
>

There isn't one at present.  I think it makes a lot of sense to
support *BSD in IcedTea proper (including 6).  CCing to the BSD
developers to see if they have any thoughts on this.

> 3. Are there some simple tasks I can do such as patch diffs or something on
> patches that won't apply?
>

You'll need to do that locally.  I'm not sure how much help
contributing these back will be until we know how to proceed with
this, especially as some will just be because the BSD tree is some old
OpenJDK7 version.

> Thanks,
> Eric
>
> On Tue, Jan 13, 2009 at 8:35 PM, Andrew John Hughes
> <gnu_andrew at member.fsf.org> wrote:
>>
>> 2009/1/14 Michael Franz <mvfranz at gmail.com>:
>> > Hi,
>> >
>> > I have been trying to find documentation on how the bootstrap build
>> > works on
>> > IcedTea, but have not found it.  I have tried to read the Makefile, but
>> > I
>> > must admit I am not that proficient with makefiles.
>> >
>>
>> That would be a little difficult, given most of the makefiles are part
>> of the OpenJDK build which is downloaded by IcedTea i.e. if you're
>> looking at just what comes from a Mercurial checkout or a tarball,
>> it'll not make a lot of sense...
>>
>> > If there is no documentation, perhaps answers to these question will
>> > help
>> > me.
>>
>> If you couldn't find any, what there is is too well hidden...
>>
>> >
>> > 1. How many passes (full compilations) are there done on the source
>> > before
>> > the final jdk is complete?
>>
>> By default, 2.  OpenJDK is built once with the system JDK.  This is
>> assumed to be gcj/ecj or some other GNU Classpath variant as these are
>> the only Free options other than IcedTea/OpenJDK itself (saying that,
>> I suppose there is Harmony but I don't know of anyone trying to build
>> with that and whether that also needs a JDK to build too).  This
>> applies some additional patches (located in patches/ecj) which disable
>> a few things, remove some Sun-specific assumptions, etc.  Sorry to be
>> a bit vague, but we probably do need to go through the patch to see
>> what's in there and what's still needed.
>>
>> The built JDK is then tested by being used to build OpenJDK.  If you
>> already have IcedTea (say from your distro), you can skip straight to
>> this stage using --with-icedtea and --with-icedtea-home to specify a
>> path to your existing IcedTea installation if the default is no good
>> (these two options should be combined IMO).  The system IcedTea needs
>> to be fairly new as some IcedTea plugin stuff is assumed to be
>> presented AFAIR.
>>
>> The alternate builds (zero assembler, shark, cacao) follow the same
>> process; their alterations primarily affect HotSpot.
>>
>> > 2. How much (if any) of the source that is being built is compiled and
>> > put
>> > into the rt-closed.jar?
>>
>> An ecj step before the OpenJDK build compiles enough of the OpenJDK
>> sources separately to satisfy the OpenJDK build.  The OpenJDK build is
>> designed only for Sun JDKs it seems, and so relies on a lot of
>> Sun-specific classes being present in the build JDK (far over and
>> above what's in the spec.).  These are added to rt-closed.jar (the
>> naming is from the OpenJDK build assuming this is an existing
>> proprietary JDK IIRC).  What is included has been found by trial and
>> error.  For instance, javax/script was recently added to the list as
>> it's needed by newer versions of HotSpot.  The list can be found as
>> ICEDTEA_COPY_DIRS in Makefile.am:
>>
>> # Sources copied from OpenJDK.
>> ICEDTEA_COPY_DIRS = \
>>        com/sun/jdi \
>>        com/sun/jdi/connect \
>>        com/sun/jdi/connect/spi \
>>        com/sun/jdi/event \
>>        com/sun/jdi/request \
>>        com/sun/jmx/snmp/agent \
>>        com/sun/tools/jdi \
>>        java/io \
>>        java/util \
>>        java/rmi \
>>        sun/awt/ \
>>        javax/net/ssl
>>
>> if WITH_ALT_HSBUILD
>> ICEDTEA_COPY_DIRS += \
>>        javax/script
>> endif
>>
>> This is from IcedTea6.  Note that the SNMP stuff is stubbed, and
>> should probably just be removed and IMPORT_BINARY_PLUGS=false set on
>> the OpenJDK build.
>>
>> > 3. Is rt-closed.jar all that should be needed to compile the JDK the
>> > first
>> > time?
>>
>> Yes, as explained above.
>>
>> > 4. What is the expected results of a successful bootstrap?
>>
>> A fully-compliant 1.6 JDK? :)
>> You should get:
>>
>> IcedTea is served.
>>
>> when you reach the end.  The results are in
>> openjdk/control/build/${OS}-${ARCH}/j2sdk-image (omit the 'control'
>> segment on IcedTea7).
>>
>> The easiest way to try a pain-free build is to try it on Fedora where
>> it should just ./configure and make.
>>
>> >
>> > Thanks
>> >
>> > Michael
>> >
>> >
>>
>> Thanks,
>> --
>> Andrew :-)
>>
>> 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
>
>



-- 
Andrew :-)

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


From gbenson at redhat.com  Thu Jan 15 06:15:43 2009
From: gbenson at redhat.com (Gary Benson)
Date: Thu, 15 Jan 2009 14:15:43 +0000
Subject: changeset in /hg/icedtea6: 2009-01-15  Gary Benson  <gbenson@red...
Message-ID: <hg.9ecdf73ae0e1.1232028943.2873452341184383832@icedtea.classpath.org>

changeset 9ecdf73ae0e1 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=9ecdf73ae0e1
description:
	2009-01-15  Gary Benson  <gbenson at redhat.com>

		* ports/hotspot/src/cpu/zero/vm/globals_zero.hpp
		(StackShadowPages): Increase for 64-bit builds.

diffstat:

2 files changed, 23 insertions(+), 18 deletions(-)
ChangeLog                                      |    5 +++
ports/hotspot/src/cpu/zero/vm/globals_zero.hpp |   36 ++++++++++++------------

diffs (68 lines):

diff -r 3b8609a88eaf -r 9ecdf73ae0e1 ChangeLog
--- a/ChangeLog	Tue Jan 13 22:27:58 2009 -0500
+++ b/ChangeLog	Thu Jan 15 09:14:52 2009 -0500
@@ -1,3 +1,8 @@ 2009-01-13  Omair Majid  <omajid at redhat.
+2009-01-15  Gary Benson  <gbenson at redhat.com>
+
+	* ports/hotspot/src/cpu/zero/vm/globals_zero.hpp
+	(StackShadowPages): Increase for 64-bit builds.
+
 2009-01-13  Omair Majid  <omajid at redhat.com>
 
 	* rt/net/sourceforge/jnlp/cache/ResourceTracker.java
diff -r 3b8609a88eaf -r 9ecdf73ae0e1 ports/hotspot/src/cpu/zero/vm/globals_zero.hpp
--- a/ports/hotspot/src/cpu/zero/vm/globals_zero.hpp	Tue Jan 13 22:27:58 2009 -0500
+++ b/ports/hotspot/src/cpu/zero/vm/globals_zero.hpp	Thu Jan 15 09:14:52 2009 -0500
@@ -1,6 +1,6 @@
 /*
  * Copyright 2000-2006 Sun Microsystems, Inc.  All Rights Reserved.
- * Copyright 2007 Red Hat, Inc.
+ * Copyright 2007, 2008, 2009 Red Hat, Inc.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -28,27 +28,27 @@
 // runtime system.  See globals.hpp for details of what they do.
 //
 
-define_pd_global(bool,  ConvertSleepToYield,      true);
-define_pd_global(bool,  ShareVtableStubs,         true);
-define_pd_global(bool,  CountInterpCalls,         true);
-define_pd_global(bool,  NeedsDeoptSuspend,        false);
+define_pd_global(bool,  ConvertSleepToYield,  true);
+define_pd_global(bool,  ShareVtableStubs,     true);
+define_pd_global(bool,  CountInterpCalls,     true);
+define_pd_global(bool,  NeedsDeoptSuspend,    false);
 
-define_pd_global(bool,  ImplicitNullChecks,       true);
-define_pd_global(bool,  UncommonNullCast,         true);
+define_pd_global(bool,  ImplicitNullChecks,   true);
+define_pd_global(bool,  UncommonNullCast,     true);
 
-define_pd_global(intx,  CodeEntryAlignment,       32);
-define_pd_global(uintx, TLABSize,                 0);
+define_pd_global(intx,  CodeEntryAlignment,   32);
+define_pd_global(uintx, TLABSize,             0);
 #ifdef _LP64
-define_pd_global(uintx, NewSize, ScaleForWordSize(2048 * K));
+define_pd_global(uintx, NewSize,              ScaleForWordSize(2048 * K));
 #else
-define_pd_global(uintx, NewSize, ScaleForWordSize(1024 * K));
+define_pd_global(uintx, NewSize,              ScaleForWordSize(1024 * K));
 #endif // _LP64
-define_pd_global(intx,  InlineFrequencyCount,     100);
-define_pd_global(intx,  PreInflateSpin,           10);
+define_pd_global(intx,  InlineFrequencyCount, 100);
+define_pd_global(intx,  PreInflateSpin,       10);
 
-define_pd_global(intx,  StackYellowPages,         2);
-define_pd_global(intx,  StackRedPages,            1);
-define_pd_global(intx,  StackShadowPages,         3 DEBUG_ONLY(+3));
+define_pd_global(intx,  StackYellowPages,     2);
+define_pd_global(intx,  StackRedPages,        1);
+define_pd_global(intx,  StackShadowPages,     3 LP64_ONLY(+3) DEBUG_ONLY(+3));
 
-define_pd_global(bool,  RewriteBytecodes,         true);
-define_pd_global(bool,  RewriteFrequentPairs,     true);
+define_pd_global(bool,  RewriteBytecodes,     true);
+define_pd_global(bool,  RewriteFrequentPairs, true);


From omajid at redhat.com  Thu Jan 15 13:19:09 2009
From: omajid at redhat.com (Omair Majid)
Date: Thu, 15 Jan 2009 21:19:09 +0000
Subject: changeset in /hg/icedtea6: 2009-01-15  Omair Majid  <omajid@redh...
Message-ID: <hg.91c3966fbc7a.1232054349.2873452341184383832@icedtea.classpath.org>

changeset 91c3966fbc7a in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=91c3966fbc7a
description:
	2009-01-15  Omair Majid  <omajid at redhat.com>

	    * patches/icedtea-a11y-property-change.patch: Removed incorrect patch.
	    * HACKING: Remove above patch.
	    * Makefile.am (ICEDTEA_PATCHES): Removed patch.

diffstat:

4 files changed, 6 insertions(+), 19 deletions(-)
ChangeLog                                  |    6 ++++++
HACKING                                    |    1 -
Makefile.am                                |    1 -
patches/icedtea-a11y-property-change.patch |   17 -----------------

diffs (56 lines):

diff -r 9ecdf73ae0e1 -r 91c3966fbc7a ChangeLog
--- a/ChangeLog	Thu Jan 15 09:14:52 2009 -0500
+++ b/ChangeLog	Thu Jan 15 16:18:23 2009 -0500
@@ -1,3 +1,9 @@ 2009-01-15  Gary Benson  <gbenson at redhat
+2009-01-15  Omair Majid  <omajid at redhat.com>
+
+	* patches/icedtea-a11y-property-change.patch: Removed incorrect patch.
+	* HACKING: Remove above patch.
+	* Makefile.am (ICEDTEA_PATCHES): Removed patch.
+
 2009-01-15  Gary Benson  <gbenson at redhat.com>
 
 	* ports/hotspot/src/cpu/zero/vm/globals_zero.hpp
diff -r 9ecdf73ae0e1 -r 91c3966fbc7a HACKING
--- a/HACKING	Thu Jan 15 09:14:52 2009 -0500
+++ b/HACKING	Thu Jan 15 16:18:23 2009 -0500
@@ -78,7 +78,6 @@ The following patches are currently appl
 * icedtea-format-warnings.patch: Fix build failures with -Wformat=1.
 * icedtea-io_util-overflow.patch: Replace some code to correctly handle overflows. (S6788196)
 * icedtea-cc-interp-jvmti.patch: Disable some JVMTI capabilities which are unsupported or do not work with the C++ interpreter.
-* icedtea-a11y-property-change.patch: Dont fire PropertyChangeEvent if the property hasnt changed.
 * icedtea-demo-swingapplet.patch: Add missing html file needed to run the demo.
 * icedtea-6791168.patch: Fix build failure with GCC-4.4 (PR 38725) and compiler warnings.
 * icedtea-no-precompiled.patch: Don't use precompiled header files in hotspot.
diff -r 9ecdf73ae0e1 -r 91c3966fbc7a Makefile.am
--- a/Makefile.am	Thu Jan 15 09:14:52 2009 -0500
+++ b/Makefile.am	Thu Jan 15 16:18:23 2009 -0500
@@ -690,7 +690,6 @@ endif
 
 ICEDTEA_PATCHES += \
 	$(DISTRIBUTION_PATCHES) \
-	patches/icedtea-a11y-property-change.patch \
 	patches/icedtea-demo-swingapplet.patch \
 	patches/icedtea-awt-window-size.patch
 
diff -r 9ecdf73ae0e1 -r 91c3966fbc7a patches/icedtea-a11y-property-change.patch
--- a/patches/icedtea-a11y-property-change.patch	Thu Jan 15 09:14:52 2009 -0500
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,17 +0,0 @@
---- AccessibleContext.java.orig	2008-12-24 11:33:22.000000000 -0500
-+++ openjdk/jdk/src/share/classes/javax/accessibility/AccessibleContext.java	2008-12-24 11:35:29.000000000 -0500
-@@ -736,6 +736,14 @@
-                                    Object oldValue,
-                                    Object newValue) {
-         if (accessibleChangeSupport != null) {
-+
-+            if (oldValue == newValue) {
-+                return;
-+            }
-+            if (oldValue != null && newValue != null && oldValue.equals(newValue)) {
-+                return;
-+            }
-+
-             if (newValue instanceof PropertyChangeEvent) {
-                 PropertyChangeEvent pce = (PropertyChangeEvent)newValue;
-                 accessibleChangeSupport.firePropertyChange(pce);


From mark at klomp.org  Thu Jan 15 16:46:31 2009
From: mark at klomp.org (Mark Wielaard)
Date: Fri, 16 Jan 2009 01:46:31 +0100
Subject: Public open specs
In-Reply-To: <493D1250.7090007@Sun.COM>
References: <20080917084136.GA10250@bamboo.destinee.acro.gen.nz>
	<1226579378.4563.15.camel@dijkstra.wildebeest.org>
	<491C9E25.6050301@sun.com>
	<1226614223.10363.4.camel@hermans.wildebeest.org>
	<491CAD1C.8040106@sun.com>
	<1226619088.5290.4.camel@dijkstra.wildebeest.org>
	<491D858C.70109@sun.com>
	<1226674908.3266.58.camel@dijkstra.wildebeest.org>
	<491DC160.4030004@sun.com>
	<1226739682.16426.29.camel@hermans.wildebeest.org>
	<17c6771e0811151650g798290b3t7f76f78bb463442b@mail.gmail.com>
	<49219AF0.6070407@sun.com>
	<1228736965.3712.14.camel@dijkstra.wildebeest.org>
	<493D1250.7090007@Sun.COM>
Message-ID: <1232066791.3379.61.camel@hermans.wildebeest.org>

Hi Dalibor,

On Mon, 2008-12-08 at 13:25 +0100, Dalibor Topic wrote:
> On 12/ 8/08 12:49 PM, Mark Wielaard wrote:
> > On Mon, 2008-11-17 at 17:25 +0100, Dalibor Topic wrote:
> >> Thank you both for taking the time to explain your concerns, and
> >> provide me with a toolchest of arguments to pick from.
> >>
> >> I'll go work on my poking tools now.
> >
> > Much appreciated. Please do let us know what the progress/timeline is.
> > If we can do anything to speed things up, just yell. Should we move this
> > thread to the general discuss mailinglist?
>
> Since I'll be at Devoxx later this week, and a bunch of other people 
> involved should be there, too, I plan to have some face to face
> conversations about it there and then. 
> Usually finding time to get everyone in the same spot to discuss such
> issues is really hard in my experience, as everyone is terribly busy
> doing all kinds of other OpenJDK (un)related things, but 
> that's exactly what conferences like Devoxx are for. ;)

Hope you had a great and productive time at Devoxx. How did the
discussions go and what is the new timeline for opening up these
documents?

Thanks,

Mark



From mvyskocil at suse.cz  Fri Jan 16 01:51:38 2009
From: mvyskocil at suse.cz (Michal Vyskocil)
Date: Fri, 16 Jan 2009 10:51:38 +0100
Subject: [PATCH] No return in nonvoid function
Message-ID: <200901161051.38561.mvyskocil@suse.cz>

Hi,

according a new rules in SUSE is the compiler warning in $SUBJ checked as an 
error and must be fixed. I attach a small patch which add some returns, which 
are not useful in many cases, but turn off the compiler warning.

The patch is against openjdk b14 and a latest (well, from Monday :)) checkout 
of icedtea.

Regards
Michal Vyskocil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openjdk-6-src-b14-no-return-in-nonvoid-function.patch
Type: text/x-patch
Size: 1763 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090116/5cbc958a/attachment.bin 

From Dalibor.Topic at Sun.COM  Fri Jan 16 03:46:51 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Fri, 16 Jan 2009 12:46:51 +0100
Subject: Public open specs
In-Reply-To: <1232066791.3379.61.camel@hermans.wildebeest.org>
References: <20080917084136.GA10250@bamboo.destinee.acro.gen.nz>
	<1226579378.4563.15.camel@dijkstra.wildebeest.org>
	<491C9E25.6050301@sun.com>
	<1226614223.10363.4.camel@hermans.wildebeest.org>
	<491CAD1C.8040106@sun.com>
	<1226619088.5290.4.camel@dijkstra.wildebeest.org>
	<491D858C.70109@sun.com>
	<1226674908.3266.58.camel@dijkstra.wildebeest.org>
	<491DC160.4030004@sun.com>
	<1226739682.16426.29.camel@hermans.wildebeest.org>
	<17c6771e0811151650g798290b3t7f76f78bb463442b@mail.gmail.com>
	<49219AF0.6070407@sun.com>
	<1228736965.3712.14.camel@dijkstra.wildebeest.org>
	<493D1250.7090007@Sun.COM>
	<1232066791.3379.61.camel@hermans.wildebeest.org>
Message-ID: <497073AB.1010302@Sun.COM>

On 01/16/09 01:46, Mark Wielaard wrote:
> Hi Dalibor,
> Hope you had a great and productive time at Devoxx. 
Yes, thanks you!
> How did the
> discussions go and what is the new timeline for opening up these
> documents?
>   
The discussions were brief. There is no timeline, since there is no 
decision made by
Sun to do it - I'm looking at your idea on my own in order to figure out how
(and when) to make a good case for it.

Changing anything regarding the JCP is a massive, politically 
challenging process -
assuming I'd be able to make a convincing case for that in the first 
place (not a given at all,
looking at the amount of  work it would potentially take to do what you 
want for about a 
dozen of already released JSRs).

cheers,
dalibor topic

-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer
Vorsitzender des Aufsichtsrates: Martin H?ring



From kurt at intricatesoftware.com  Fri Jan 16 07:02:56 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Fri, 16 Jan 2009 10:02:56 -0500
Subject: IcedTea Bootstrap Process
In-Reply-To: <17c6771e0901141657o7d717a52i621c9a0b25f2a666@mail.gmail.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>	<17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>	<860cb0120901141627m5cf7fdeke99ed7e111113e56@mail.gmail.com>
	<17c6771e0901141657o7d717a52i621c9a0b25f2a666@mail.gmail.com>
Message-ID: <4970A1A0.4030603@intricatesoftware.com>

Hello Andrew,

Andrew John Hughes wrote:
> 2009/1/15 Eric Richardson <ekrichardson at gmail.com>:
>> 2. It seems that there are tons of makefile changes and such brewing on the
>> bsd-ports list that might help us on Mac OS X. What is the mechanism for
>> these to flow into Icedtea?
>>
> 
> There isn't one at present.  I think it makes a lot of sense to
> support *BSD in IcedTea proper (including 6).  CCing to the BSD
> developers to see if they have any thoughts on this.

Basically it comes down to lack of resources. If I could work full time
on bsd-java many things could be considered like merging our work. With
the available time I have I would like to work towards getting bsd
support included in the main tree.

I'm not sure you know this but I've been working on bsd java support
with Sun's JVM for about five years and Greg a few years more then that.
We have merged and merged and merged our work countless times as the JDK
has moved forward. There are about 250 individual files that are patched
to add bsd support. Getting these into the main tree would save us
countless hours of future merging and free us to work on improving the
port with our open-source time.

>> 3. Are there some simple tasks I can do such as patch diffs or something on
>> patches that won't apply?
>>
> 
> You'll need to do that locally.  I'm not sure how much help
> contributing these back will be until we know how to proceed with
> this, especially as some will just be because the BSD tree is some old
> OpenJDK7 version.

Actually the bsd-port tree is not old, I'm not sure why you thought that.

Regards,
-Kurt


From doko at ubuntu.com  Fri Jan 16 07:27:57 2009
From: doko at ubuntu.com (Matthias Klose)
Date: Fri, 16 Jan 2009 16:27:57 +0100
Subject: comparing jtreg test results
Message-ID: <4970A77D.3080003@ubuntu.com>

[this is all done using IcedTea builds]

Comparing 6b12 and 6b14 builds on ix86 I do see some regressions in the tests
(compared by diffing the log output):

jdk:
+FAILED: com/sun/jdi/EarlyReturnNegativeTest.java
+FAILED: com/sun/jdi/NewInstanceTest.java
+FAILED: com/sun/jdi/RedefineCrossEvent.java
+FAILED: javax/crypto/Cipher/TestGetInstance.java
+FAILED: javax/naming/ldap/LdapName/CompareToEqualsTests.java
+FAILED: sun/rmi/rmic/RMIGenerator/RmicDefault.java
+FAILED: sun/security/util/Oid/OidFormat.java
+FAILED: sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java
+FAILED: sun/security/x509/AVA/EmailAddressEncoding.java
+FAILED: sun/security/x509/X500Name/AllAttribs.java

Some tests just disappear (assuming this is due to the hotspot import in icedtea):

hotspot:
-Passed: compiler/6547163/Test.java
-Passed: compiler/6563987/Test.java
-Passed: compiler/6571539/Test.java
-Passed: compiler/6595044/Main.java
-Passed: compiler/6707044/LuceneCrash.java

Can somebody reproduce these?

Then when running the testsuite with the xvfb xserver, I get many errors "Cannot
connect to the X server", although the mauve testsuite runs fine with the xvfb
server.

  Matthias



The single failures:
+FAILED: com/sun/jdi/EarlyReturnNegativeTest.java

EarlyReturnNegativeTest: failed
debugee in doit
----------System.err:(32/2097)----------
run args: [EarlyReturnNegativeTarg]
failure: com.sun.jdi.ClassNotLoadedException: Class java.lang.Object not loaded
com.sun.jdi.ClassNotLoadedException: Class java.lang.Object not loaded
        at
com.sun.tools.jdi.ClassLoaderReferenceImpl.findType(ClassLoaderReferenceImpl.java:106)
        at com.sun.tools.jdi.ReferenceTypeImpl.findType(ReferenceTypeImpl.java:1168)
        at com.sun.tools.jdi.MethodImpl.findType(MethodImpl.java:148)
        at
com.sun.tools.jdi.MethodImpl$ReturnContainer.findType(MethodImpl.java:241)
        at
com.sun.tools.jdi.ArrayReferenceImpl.validateAssignment(ArrayReferenceImpl.java:243)
        at
com.sun.tools.jdi.ObjectReferenceImpl.prepareForAssignmentTo(ObjectReferenceImpl.java:557)
        at com.sun.tools.jdi.ValueImpl.prepareForAssignment(ValueImpl.java:48)
        at
com.sun.tools.jdi.ThreadReferenceImpl.forceEarlyReturn(ThreadReferenceImpl.java:532)
        at EarlyReturnNegativeTest.doEarly(EarlyReturnNegativeTest.java:212)
        at
EarlyReturnNegativeTest.breakpointReached(EarlyReturnNegativeTest.java:262)
        at TestScaffold$EventHandler.notifyEvent(TestScaffold.java:191)
        at TestScaffold$EventHandler.run(TestScaffold.java:275)
        at java.lang.Thread.run(Thread.java:636)
java.lang.Exception: EarlyReturnNegativeTest: failed
        at EarlyReturnNegativeTest.runTests(EarlyReturnNegativeTest.java:370)
        at TestScaffold.startTests(TestScaffold.java:429)
        at EarlyReturnNegativeTest.main(EarlyReturnNegativeTest.java:189)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
        at java.lang.Thread.run(Thread.java:636)

+FAILED: com/sun/jdi/NewInstanceTest.java

----------System.err:(23/1367)----------
run args: [NewInstanceTarg]
Making array for field: objArray
com.sun.jdi.ClassNotLoadedException: Class java.lang.Object[] not loaded
        at
com.sun.tools.jdi.ClassLoaderReferenceImpl.findType(ClassLoaderReferenceImpl.java:106)
        at com.sun.tools.jdi.ReferenceTypeImpl.findType(ReferenceTypeImpl.java:1168)
        at com.sun.tools.jdi.FieldImpl.findType(FieldImpl.java:73)
        at com.sun.tools.jdi.FieldImpl.type(FieldImpl.java:68)
        at NewInstanceTest.makeArray(NewInstanceTest.java:81)
        at NewInstanceTest.runTests(NewInstanceTest.java:97)
        at TestScaffold.startTests(TestScaffold.java:429)
        at NewInstanceTest.main(NewInstanceTest.java:73)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
        at java.lang.Thread.run(Thread.java:636)
IOException reading output of child java interpreter:Stream closed


+FAILED: com/sun/jdi/RedefineCrossEvent.java

run args: [-redefstart, -redefevent, NewInstanceTarg]
Redefining class NewInstanceTarg (loaded by instance of
sun.misc.Launcher$AppClassLoader(id=51))
Redefining class NewInstanceTarg (loaded by instance of
sun.misc.Launcher$AppClassLoader(id=51))
Making array for field: objArray
com.sun.jdi.ClassNotLoadedException: Class java.lang.Object[] not loaded
        at
com.sun.tools.jdi.ClassLoaderReferenceImpl.findType(ClassLoaderReferenceImpl.java:106)
        at com.sun.tools.jdi.ReferenceTypeImpl.findType(ReferenceTypeImpl.java:1168)
        at com.sun.tools.jdi.FieldImpl.findType(FieldImpl.java:73)
        at com.sun.tools.jdi.FieldImpl.type(FieldImpl.java:68)
        at NewInstanceTest.makeArray(NewInstanceTest.java:81)
        at NewInstanceTest.runTests(NewInstanceTest.java:97)
        at TestScaffold.startTests(TestScaffold.java:429)
        at NewInstanceTest.main(NewInstanceTest.java:73)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
        at java.lang.Thread.run(Thread.java:636)

JavaTest Message: Test threw exception: com.sun.jdi.ClassNotLoadedException:
Class java.lang.Object[] not loaded
JavaTest Message: shutting down test

+FAILED: javax/crypto/Cipher/TestGetInstance.java

----------System.err:(14/747)----------
java.security.NoSuchAlgorithmException: No such algorithm: foo
        at javax.crypto.Cipher.getInstance(Cipher.java:589)
        at javax.crypto.Cipher.getInstance(Cipher.java:510)
        at TestGetInstance.main(TestGetInstance.java:134)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595)
        at java.lang.Thread.run(Thread.java:636)

JavaTest Message: Test threw exception: java.security.NoSuchAlgorithmException
JavaTest Message: shutting down test


+FAILED: javax/naming/ldap/LdapName/CompareToEqualsTests.java

Checking name1: cn=config and name2: Cn=COnFIG
name1.hashCode(): 1993513894 name2.hashCode(): 1993506733
----------System.err:(13/715)----------
java.lang.Exception: hashCode test failed for name1:cn=config name2:Cn=COnFIG
        at CompareToEqualsTests.checkResults(CompareToEqualsTests.java:118)
        at CompareToEqualsTests.main(CompareToEqualsTests.java:65)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595)
        at java.lang.Thread.run(Thread.java:636)

JavaTest Message: Test threw exception: java.lang.Exception
JavaTest Message: shutting down test


+FAILED: sun/rmi/rmic/RMIGenerator/RmicDefault.java


+FAILED: sun/security/util/Oid/OidFormat.java

Trying 0
java.io.IOException: ObjectIdentifier() -- Must be at least two oid components
java.lang.NullPointerException
        at sun.security.x509.AlgorithmId.algOID(AlgorithmId.java:568)
        at sun.security.x509.AlgorithmId.get(AlgorithmId.java:409)
        at
javax.crypto.EncryptedPrivateKeyInfo.<init>(EncryptedPrivateKeyInfo.java:137)
        at OidFormat.testBad(OidFormat.java:154)
        at OidFormat.main(OidFormat.java:57)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595)
        at java.lang.Thread.run(Thread.java:636)

JavaTest Message: Test threw exception: java.lang.NullPointerException
JavaTest Message: shutting down test

+FAILED: sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java

----------messages:(3/141)----------
command: main ExtensibleAlgorithmId
reason: Assumed action based on file name: run main ExtensibleAlgorithmId
elapsed time (seconds): 0.002
----------System.out:(0/0)----------
----------System.err:(15/806)----------
java.lang.NullPointerException
        at sun.security.x509.AlgorithmId.algOID(AlgorithmId.java:568)
        at sun.security.x509.AlgorithmId.get(AlgorithmId.java:409)
        at sun.security.x509.AlgorithmId.getAlgorithmId(AlgorithmId.java:395)
        at ExtensibleAlgorithmId.main(ExtensibleAlgorithmId.java:38)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595)
        at java.lang.Thread.run(Thread.java:636)

JavaTest Message: Test threw exception: java.lang.NullPointerException
JavaTest Message: shutting down test

+FAILED: sun/security/x509/AVA/EmailAddressEncoding.java

----------messages:(3/139)----------
command: main EmailAddressEncoding
reason: Assumed action based on file name: run main EmailAddressEncoding
elapsed time (seconds): 0.002
----------System.out:(0/0)----------
----------System.err:(23/1298)----------
java.lang.IllegalArgumentException: improperly specified input name: c=us,
emailaddress=foo at bar, cn=foobar
        at javax.security.auth.x500.X500Principal.<init>(X500Principal.java:169)
        at javax.security.auth.x500.X500Principal.<init>(X500Principal.java:121)
        at EmailAddressEncoding.main(EmailAddressEncoding.java:39)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595)
        at java.lang.Thread.run(Thread.java:636)
Caused by: java.io.IOException: Invalid keyword "EMA?LADDRESS"
        at sun.security.x509.AVAKeyword.getOID(AVA.java:1268)
        at sun.security.x509.AVA.<init>(AVA.java:192)
        at sun.security.x509.AVA.<init>(AVA.java:145)
        at sun.security.x509.RDN.<init>(RDN.java:151)
        at sun.security.x509.X500Name.parseDN(X500Name.java:918)
        at sun.security.x509.X500Name.<init>(X500Name.java:165)
        at javax.security.auth.x500.X500Principal.<init>(X500Principal.java:167)
        ... 8 more

JavaTest Message: Test threw exception: java.lang.IllegalArgumentException
JavaTest Message: shutting down test

+FAILED: sun/security/x509/X500Name/AllAttribs.java

----------messages:(3/119)----------
command: main AllAttribs
reason: Assumed action based on file name: run main AllAttribs
elapsed time (seconds): 0.001
----------System.out:(0/0)----------
----------System.err:(19/965)----------
java.io.IOException: Invalid keyword "G?VENNAME"
        at sun.security.x509.AVAKeyword.getOID(AVA.java:1268)
        at sun.security.x509.AVA.<init>(AVA.java:192)
        at sun.security.x509.AVA.<init>(AVA.java:145)
        at sun.security.x509.RDN.<init>(RDN.java:151)
        at sun.security.x509.X500Name.parseDN(X500Name.java:918)
        at sun.security.x509.X500Name.<init>(X500Name.java:165)
        at sun.security.x509.X500Name.<init>(X500Name.java:152)
        at AllAttribs.main(AllAttribs.java:37)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.sun.javatest.regtest.MainAction$SameVMThread.run(MainAction.java:595)
        at java.lang.Thread.run(Thread.java:636)

JavaTest Message: Test threw exception: java.io.IOException
JavaTest Message: shutting down test


  Matthias



From gnu_andrew at member.fsf.org  Fri Jan 16 11:59:46 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 16 Jan 2009 19:59:46 +0000
Subject: IcedTea Bootstrap Process
In-Reply-To: <4970A1A0.4030603@intricatesoftware.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>
	<17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>
	<860cb0120901141627m5cf7fdeke99ed7e111113e56@mail.gmail.com>
	<17c6771e0901141657o7d717a52i621c9a0b25f2a666@mail.gmail.com>
	<4970A1A0.4030603@intricatesoftware.com>
Message-ID: <17c6771e0901161159s1e1b0d83lb861b699f83246dc@mail.gmail.com>

2009/1/16 Kurt Miller <kurt at intricatesoftware.com>:
> Hello Andrew,
>
> Andrew John Hughes wrote:
>> 2009/1/15 Eric Richardson <ekrichardson at gmail.com>:
>>> 2. It seems that there are tons of makefile changes and such brewing on the
>>> bsd-ports list that might help us on Mac OS X. What is the mechanism for
>>> these to flow into Icedtea?
>>>
>>
>> There isn't one at present.  I think it makes a lot of sense to
>> support *BSD in IcedTea proper (including 6).  CCing to the BSD
>> developers to see if they have any thoughts on this.
>
> Basically it comes down to lack of resources. If I could work full time
> on bsd-java many things could be considered like merging our work. With
> the available time I have I would like to work towards getting bsd
> support included in the main tree.
>

I see your point and agree whole-heartedly.  The issue is that there
are in effect two main trees: the OpenJDK6 tree (which is being used,
patched by IcedTea6, in many GNU/Linux distributions) and the OpenJDK7
tree which the BSD tree is currently pulling from.  The problem with 7
is that, while it gets a lot more TLC from Sun, it could be a couple
of years before we see 7 replacing 6 for users and this ties BSD
support to the same timeline.  For me, it would be nice to see *BSD
support sooner than that.

Has there been any thought about support from the various BSD
distributions and the Free stuff that runs on top of Mac OS X?

> I'm not sure you know this but I've been working on bsd java support
> with Sun's JVM for about five years and Greg a few years more then that.
> We have merged and merged and merged our work countless times as the JDK
> has moved forward. There are about 250 individual files that are patched
> to add bsd support. Getting these into the main tree would save us
> countless hours of future merging and free us to work on improving the
> port with our open-source time.

Yes I am aware of this and I'd also like to see things change.
However, I'm not sure getting it into the OpenJDK7 tree would help
anything, unless Sun are also intending to test and ship their own
binaries for BSD platforms.

>
>>> 3. Are there some simple tasks I can do such as patch diffs or something on
>>> patches that won't apply?
>>>
>>
>> You'll need to do that locally.  I'm not sure how much help
>> contributing these back will be until we know how to proceed with
>> this, especially as some will just be because the BSD tree is some old
>> OpenJDK7 version.
>
> Actually the bsd-port tree is not old, I'm not sure why you thought that.
>

Sorry, I should have been clearer.  I haven't looked at the BSD tree
myself but the problems Eric was seeing suggest that the sources he's
using from the BSD tree are either outdated or have changed for the
BSD port, causing the patches to not apply.  In reality, the cause for
each patch may be one of these or even both.

> Regards,
> -Kurt
>

Thanks,
-- 
Andrew :-)

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


From kurt at intricatesoftware.com  Fri Jan 16 14:07:56 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Fri, 16 Jan 2009 17:07:56 -0500
Subject: IcedTea Bootstrap Process
In-Reply-To: <17c6771e0901161159s1e1b0d83lb861b699f83246dc@mail.gmail.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>	
	<17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>	
	<860cb0120901141627m5cf7fdeke99ed7e111113e56@mail.gmail.com>	
	<17c6771e0901141657o7d717a52i621c9a0b25f2a666@mail.gmail.com>	
	<4970A1A0.4030603@intricatesoftware.com>
	<17c6771e0901161159s1e1b0d83lb861b699f83246dc@mail.gmail.com>
Message-ID: <4971053C.50609@intricatesoftware.com>

Andrew John Hughes wrote:
> 2009/1/16 Kurt Miller <kurt at intricatesoftware.com>:
>> Hello Andrew,
>>
>> Andrew John Hughes wrote:
>>> 2009/1/15 Eric Richardson <ekrichardson at gmail.com>:
>>>> 2. It seems that there are tons of makefile changes and such brewing on the
>>>> bsd-ports list that might help us on Mac OS X. What is the mechanism for
>>>> these to flow into Icedtea?
>>>>
>>> There isn't one at present.  I think it makes a lot of sense to
>>> support *BSD in IcedTea proper (including 6).  CCing to the BSD
>>> developers to see if they have any thoughts on this.
>> Basically it comes down to lack of resources. If I could work full time
>> on bsd-java many things could be considered like merging our work. With
>> the available time I have I would like to work towards getting bsd
>> support included in the main tree.
>>
> 
> I see your point and agree whole-heartedly.  The issue is that there
> are in effect two main trees: the OpenJDK6 tree (which is being used,
> patched by IcedTea6, in many GNU/Linux distributions) and the OpenJDK7
> tree which the BSD tree is currently pulling from.  The problem with 7
> is that, while it gets a lot more TLC from Sun, it could be a couple
> of years before we see 7 replacing 6 for users and this ties BSD
> support to the same timeline.  For me, it would be nice to see *BSD
> support sooner than that.

True. At some point we will get to OpenJDK6 too. For now I'm following
the standard practice of following current/HEAD/tip to increase the
likelihood of our work making it in the main tree. If it turns out that
Sun isn't interested in merging BSD support into the main tree I would
expect that we will change our focus to OpenJDK6.

> Has there been any thought about support from the various BSD
> distributions and the Free stuff that runs on top of Mac OS X?

I'm open to any/all support that would allow me to work on open source
Java full time. I've not approached Apple or the FreeBSD Foundation
though. I know from past experience the FreeBSD Foundation prefers
to spend its $ on the certification process and looks to the community
for the rest of the heavy lifting. I don't have any contacts at Apple
so I wouldn't know where to start in attempting to approach them with
the idea.

>> I'm not sure you know this but I've been working on bsd java support
>> with Sun's JVM for about five years and Greg a few years more then that.
>> We have merged and merged and merged our work countless times as the JDK
>> has moved forward. There are about 250 individual files that are patched
>> to add bsd support. Getting these into the main tree would save us
>> countless hours of future merging and free us to work on improving the
>> port with our open-source time.
> 
> Yes I am aware of this and I'd also like to see things change.
> However, I'm not sure getting it into the OpenJDK7 tree would help
> anything, unless Sun are also intending to test and ship their own
> binaries for BSD platforms.

I wasn't thinking Sun would embrace supporting all the BSD's officially
with certified tested binaries. If that happened I would be pleasantly
surprised and happy. However, getting our work into the main tree would
help us keep up to date and reduce the mundane time of syncing our work
at intervals.

In any case, predicting how things will play out doesn't serve much
purpose. For now I'm content working at refining our tree to the point
where a merge could happen.

> 
>>>> 3. Are there some simple tasks I can do such as patch diffs or something on
>>>> patches that won't apply?
>>>>
>>> You'll need to do that locally.  I'm not sure how much help
>>> contributing these back will be until we know how to proceed with
>>> this, especially as some will just be because the BSD tree is some old
>>> OpenJDK7 version.
>> Actually the bsd-port tree is not old, I'm not sure why you thought that.
>>
> 
> Sorry, I should have been clearer.  I haven't looked at the BSD tree
> myself but the problems Eric was seeing suggest that the sources he's
> using from the BSD tree are either outdated or have changed for the
> BSD port, causing the patches to not apply.  In reality, the cause for
> each patch may be one of these or even both.

I haven't been following those threads too closely. It looks like he
is hitting conflicts due to IcedTea trying to patch files that we needed
to change to add BSD support.

Its been a while since I looked at IcedTea closely. The last time was
probably six months ago. IIRC back then only a RedHat branch of gcc 4.3
contained the changes needed to build IcedTea. Is that still the case or
has the gcc/gcj support been merged into gcc mainline?

Regards,
-Kurt


From mvfranz at gmail.com  Fri Jan 16 19:16:15 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Fri, 16 Jan 2009 22:16:15 -0500
Subject: IcedTea Bootstrap Process
In-Reply-To: <17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>
	<17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>
Message-ID: <fee4d890901161916l115c6625oc18858b795788295@mail.gmail.com>

Andrew,

Thanks for this detail.  It does help.  I have another question, how can I
tell what build I am in?  I run the build and it takes a while.  At some
point JAVA_CMD becomes unset and I end up with:
# Running javac:
-sourcepath
/Users/mfranz/developer/icedtea/apple5/generated:../../../src/solaris/classes:../../../src/share/classes
-bootclasspath
/Users/mfranz/developer/icedtea/apple5/bootstrap/jdk1.7.0/jre/lib/rt-closed.jar::/Users/mfranz/developer/icedtea/apple5/openjdk-ecj/build/bsd-i586/classes
-d /Users/mfranz/developer/icedtea/apple5/openjdk-ecj/build/bsd-i586/classes
@/Users/mfranz/developer/icedtea/apple5/openjdk-ecj/build/bsd-i586/tmp/java/java.lang/java/.classes.list
/bin/sh: -sourcepath: command not found

I am thinking this is the second build, but I could be wrong.  If I define
JAVA_CMD, JAVAH_CMD it gets farther, but I am probably not defining them
correctly, as the build fails.

In this case I am using a remapped Apple JDK 5 with the classpath rt.jar.

Michael

On Tue, Jan 13, 2009 at 11:35 PM, Andrew John Hughes <
gnu_andrew at member.fsf.org> wrote:

> 2009/1/14 Michael Franz <mvfranz at gmail.com>:
> > Hi,
> >
> > I have been trying to find documentation on how the bootstrap build works
> on
> > IcedTea, but have not found it.  I have tried to read the Makefile, but I
> > must admit I am not that proficient with makefiles.
> >
>
> That would be a little difficult, given most of the makefiles are part
> of the OpenJDK build which is downloaded by IcedTea i.e. if you're
> looking at just what comes from a Mercurial checkout or a tarball,
> it'll not make a lot of sense...
>
> > If there is no documentation, perhaps answers to these question will help
> > me.
>
> If you couldn't find any, what there is is too well hidden...
>
> >
> > 1. How many passes (full compilations) are there done on the source
> before
> > the final jdk is complete?
>
> By default, 2.  OpenJDK is built once with the system JDK.  This is
> assumed to be gcj/ecj or some other GNU Classpath variant as these are
> the only Free options other than IcedTea/OpenJDK itself (saying that,
> I suppose there is Harmony but I don't know of anyone trying to build
> with that and whether that also needs a JDK to build too).  This
> applies some additional patches (located in patches/ecj) which disable
> a few things, remove some Sun-specific assumptions, etc.  Sorry to be
> a bit vague, but we probably do need to go through the patch to see
> what's in there and what's still needed.
>
> The built JDK is then tested by being used to build OpenJDK.  If you
> already have IcedTea (say from your distro), you can skip straight to
> this stage using --with-icedtea and --with-icedtea-home to specify a
> path to your existing IcedTea installation if the default is no good
> (these two options should be combined IMO).  The system IcedTea needs
> to be fairly new as some IcedTea plugin stuff is assumed to be
> presented AFAIR.
>
> The alternate builds (zero assembler, shark, cacao) follow the same
> process; their alterations primarily affect HotSpot.
>
> > 2. How much (if any) of the source that is being built is compiled and
> put
> > into the rt-closed.jar?
>
> An ecj step before the OpenJDK build compiles enough of the OpenJDK
> sources separately to satisfy the OpenJDK build.  The OpenJDK build is
> designed only for Sun JDKs it seems, and so relies on a lot of
> Sun-specific classes being present in the build JDK (far over and
> above what's in the spec.).  These are added to rt-closed.jar (the
> naming is from the OpenJDK build assuming this is an existing
> proprietary JDK IIRC).  What is included has been found by trial and
> error.  For instance, javax/script was recently added to the list as
> it's needed by newer versions of HotSpot.  The list can be found as
> ICEDTEA_COPY_DIRS in Makefile.am:
>
> # Sources copied from OpenJDK.
> ICEDTEA_COPY_DIRS = \
>        com/sun/jdi \
>        com/sun/jdi/connect \
>        com/sun/jdi/connect/spi \
>        com/sun/jdi/event \
>        com/sun/jdi/request \
>        com/sun/jmx/snmp/agent \
>        com/sun/tools/jdi \
>        java/io \
>        java/util \
>        java/rmi \
>        sun/awt/ \
>        javax/net/ssl
>
> if WITH_ALT_HSBUILD
> ICEDTEA_COPY_DIRS += \
>        javax/script
> endif
>
> This is from IcedTea6.  Note that the SNMP stuff is stubbed, and
> should probably just be removed and IMPORT_BINARY_PLUGS=false set on
> the OpenJDK build.
>
> > 3. Is rt-closed.jar all that should be needed to compile the JDK the
> first
> > time?
>
> Yes, as explained above.
>
> > 4. What is the expected results of a successful bootstrap?
>
> A fully-compliant 1.6 JDK? :)
> You should get:
>
> IcedTea is served.
>
> when you reach the end.  The results are in
> openjdk/control/build/${OS}-${ARCH}/j2sdk-image (omit the 'control'
> segment on IcedTea7).
>
> The easiest way to try a pain-free build is to try it on Fedora where
> it should just ./configure and make.
>
> >
> > Thanks
> >
> > Michael
> >
> >
>
> Thanks,
> --
> Andrew :-)
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090116/464ea5f9/attachment.html 

From gnu_andrew at member.fsf.org  Fri Jan 16 20:14:38 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sat, 17 Jan 2009 04:14:38 +0000
Subject: IcedTea Bootstrap Process
In-Reply-To: <4971053C.50609@intricatesoftware.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>
	<17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>
	<860cb0120901141627m5cf7fdeke99ed7e111113e56@mail.gmail.com>
	<17c6771e0901141657o7d717a52i621c9a0b25f2a666@mail.gmail.com>
	<4970A1A0.4030603@intricatesoftware.com>
	<17c6771e0901161159s1e1b0d83lb861b699f83246dc@mail.gmail.com>
	<4971053C.50609@intricatesoftware.com>
Message-ID: <17c6771e0901162014x149d29aes8f7a76595b74e2a1@mail.gmail.com>

2009/1/16 Kurt Miller <kurt at intricatesoftware.com>:
> Andrew John Hughes wrote:
>> 2009/1/16 Kurt Miller <kurt at intricatesoftware.com>:
>>> Hello Andrew,
>>>
>>> Andrew John Hughes wrote:
>>>> 2009/1/15 Eric Richardson <ekrichardson at gmail.com>:
>>>>> 2. It seems that there are tons of makefile changes and such brewing on the
>>>>> bsd-ports list that might help us on Mac OS X. What is the mechanism for
>>>>> these to flow into Icedtea?
>>>>>
>>>> There isn't one at present.  I think it makes a lot of sense to
>>>> support *BSD in IcedTea proper (including 6).  CCing to the BSD
>>>> developers to see if they have any thoughts on this.
>>> Basically it comes down to lack of resources. If I could work full time
>>> on bsd-java many things could be considered like merging our work. With
>>> the available time I have I would like to work towards getting bsd
>>> support included in the main tree.
>>>
>>
>> I see your point and agree whole-heartedly.  The issue is that there
>> are in effect two main trees: the OpenJDK6 tree (which is being used,
>> patched by IcedTea6, in many GNU/Linux distributions) and the OpenJDK7
>> tree which the BSD tree is currently pulling from.  The problem with 7
>> is that, while it gets a lot more TLC from Sun, it could be a couple
>> of years before we see 7 replacing 6 for users and this ties BSD
>> support to the same timeline.  For me, it would be nice to see *BSD
>> support sooner than that.
>
> True. At some point we will get to OpenJDK6 too. For now I'm following
> the standard practice of following current/HEAD/tip to increase the
> likelihood of our work making it in the main tree. If it turns out that
> Sun isn't interested in merging BSD support into the main tree I would
> expect that we will change our focus to OpenJDK6.
>

Fair enough.  I'm not aware of the current situation on *BSD at the
moment, but I would assume that if an implementation is needed, 6
would be the one to go for as has happened with the GNU/Linux distros
(who understandably want to ship a certifiable complete implementation
not a JDK with no specification as yet).

>> Has there been any thought about support from the various BSD
>> distributions and the Free stuff that runs on top of Mac OS X?
>
> I'm open to any/all support that would allow me to work on open source
> Java full time. I've not approached Apple or the FreeBSD Foundation
> though. I know from past experience the FreeBSD Foundation prefers
> to spend its $ on the certification process and looks to the community
> for the rest of the heavy lifting. I don't have any contacts at Apple
> so I wouldn't know where to start in attempting to approach them with
> the idea.
>

Well the OpenJDK6 TCK process doesn't cost, though it is effectively a
self-certification process.  In the same way that RedHat has, you
and/or FreeBSD could work with the IcedTea community and certify
resulting binaries.

As to Mac OS X, I wasn't thinking of Apple, but the projects like
Mac/DarwinPorts and fink that exist to provide FOSS packages.

>>> I'm not sure you know this but I've been working on bsd java support
>>> with Sun's JVM for about five years and Greg a few years more then that.
>>> We have merged and merged and merged our work countless times as the JDK
>>> has moved forward. There are about 250 individual files that are patched
>>> to add bsd support. Getting these into the main tree would save us
>>> countless hours of future merging and free us to work on improving the
>>> port with our open-source time.
>>
>> Yes I am aware of this and I'd also like to see things change.
>> However, I'm not sure getting it into the OpenJDK7 tree would help
>> anything, unless Sun are also intending to test and ship their own
>> binaries for BSD platforms.
>
> I wasn't thinking Sun would embrace supporting all the BSD's officially
> with certified tested binaries. If that happened I would be pleasantly
> surprised and happy. However, getting our work into the main tree would
> help us keep up to date and reduce the mundane time of syncing our work
> at intervals.
>
> In any case, predicting how things will play out doesn't serve much
> purpose. For now I'm content working at refining our tree to the point
> where a merge could happen.
>

Sorry, I'm not trying to attack your methods here. It's simply my
impression that Sun may be against maintaining something in the main
tree they don't support, but you probably have a better idea of the
likelihood of it happening.

>>
>>>>> 3. Are there some simple tasks I can do such as patch diffs or something on
>>>>> patches that won't apply?
>>>>>
>>>> You'll need to do that locally.  I'm not sure how much help
>>>> contributing these back will be until we know how to proceed with
>>>> this, especially as some will just be because the BSD tree is some old
>>>> OpenJDK7 version.
>>> Actually the bsd-port tree is not old, I'm not sure why you thought that.
>>>
>>
>> Sorry, I should have been clearer.  I haven't looked at the BSD tree
>> myself but the problems Eric was seeing suggest that the sources he's
>> using from the BSD tree are either outdated or have changed for the
>> BSD port, causing the patches to not apply.  In reality, the cause for
>> each patch may be one of these or even both.
>
> I haven't been following those threads too closely. It looks like he
> is hitting conflicts due to IcedTea trying to patch files that we needed
> to change to add BSD support.
>

Yes, that's what I'm thinking too.

> Its been a while since I looked at IcedTea closely. The last time was
> probably six months ago. IIRC back then only a RedHat branch of gcc 4.3
> contained the changes needed to build IcedTea. Is that still the case or
> has the gcc/gcj support been merged into gcc mainline?
>

It was a RedHat backport to 4.1 that was required, prior to the
release of 4.3.  Now 4.3 is available, normal GCC/GCJ can be used.
It's also possible to use another Classpath VM, but you obviously need
some way of bootstrapping.  The advantage of gcj is a Java
implementation is not needed to build.

> Regards,
> -Kurt
>

Thanks,
-- 
Andrew :-)

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


From mr at sun.com  Fri Jan 16 20:47:37 2009
From: mr at sun.com (Mark Reinhold)
Date: Fri, 16 Jan 2009 20:47:37 -0800
Subject: IcedTea Bootstrap Process 
In-Reply-To: gnu_andrew@member.fsf.org; Sat, 17 Jan 2009 04:14:38 GMT;
	<17c6771e0901162014x149d29aes8f7a76595b74e2a1@mail.gmail.com> 
Message-ID: <20090117044737.BD0F0D068@callebaut.niobe.net>

> Date: Sat, 17 Jan 2009 04:14:38 +0000
> From: Andrew John Hughes <gnu_andrew at member.fsf.org>

> ...
> 
> Sorry, I'm not trying to attack your methods here. It's simply my
> impression that Sun may be against maintaining something in the main
> tree they don't support, but you probably have a better idea of the
> likelihood of it happening.

In principle I think it's a fine idea for there to be ports in the main
tree that aren't maintained by Sun -- as long as they're maintained by
someone.

- Mark


From mark at klomp.org  Sat Jan 17 09:41:38 2009
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 17 Jan 2009 17:41:38 +0000
Subject: changeset in /hg/icedtea6: Clean up samejvmsafe TEST.ROOT set.
Message-ID: <hg.3a265e06dc74.1232214098.2873452341184383832@icedtea.classpath.org>

changeset 3a265e06dc74 in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=3a265e06dc74
description:
	Clean up samejvmsafe TEST.ROOT set.

		* patches/icedtea-version.patch (samejvmsafe): Removed the following
		directories that contain test that are not samevm safe.
		javax/crypto/Cipher (TestGetInstance)
		javax/naming (CompareToEqualsTests)
		sun/rmi (RmicDefault)
		sun/security/util (OidFormat)
		sun/security/x509
		(ExtensibleAlgorithmId,EmailAddressEncoding,AllAttribs)

diffstat:

2 files changed, 12 insertions(+), 1 deletion(-)
ChangeLog                          |   11 +++++++++++
patches/icedtea-samejvm-safe.patch |    2 +-

diffs (27 lines):

diff -r 91c3966fbc7a -r 3a265e06dc74 ChangeLog
--- a/ChangeLog	Thu Jan 15 16:18:23 2009 -0500
+++ b/ChangeLog	Sat Jan 17 18:41:18 2009 +0100
@@ -1,3 +1,14 @@ 2009-01-15  Omair Majid  <omajid at redhat.
+2009-01-17  Mark Wielaard  <mark at klomp.org>
+
+	* patches/icedtea-version.patch (samejvmsafe): Removed the following
+	directories that contain test that are not samevm safe.
+	javax/crypto/Cipher (TestGetInstance)
+	javax/naming (CompareToEqualsTests)
+	sun/rmi (RmicDefault)
+	sun/security/util (OidFormat)
+	sun/security/x509
+	(ExtensibleAlgorithmId,EmailAddressEncoding,AllAttribs)
+
 2009-01-15  Omair Majid  <omajid at redhat.com>
 
 	* patches/icedtea-a11y-property-change.patch: Removed incorrect patch.
diff -r 91c3966fbc7a -r 3a265e06dc74 patches/icedtea-samejvm-safe.patch
--- a/patches/icedtea-samejvm-safe.patch	Thu Jan 15 16:18:23 2009 -0500
+++ b/patches/icedtea-samejvm-safe.patch	Sat Jan 17 18:41:18 2009 +0100
@@ -9,4 +9,4 @@
 +# -samejvm mode. Only used if the test root (dir containing this file) is
 +# given to jtreg and the -samejvm argument is used, ignored otherwise
 +# (meaning all tests are assumed to be same jvm safe).
-+samejvmsafe=com/sun/crypto com/sun/management com/sun/media com/sun/security java/beans/beancontext java/beans/PropertyChangeSupport java/beans/Statement java/beans/VetoableChangeSupport java/lang/Boolean java/lang/Byte java/lang/Double java/lang/Float java/lang/Integer java/lang/Long java/lang/Short java/lang/Math java/lang/StrictMath java/lang/String java/lang/Throwable java/lang/instrument java/math java/net/URI java/net/URLDecoder java/net/URLEncoder java/nio/Buffer java/nio/ByteOrder java/nio/MappedByteBuffer java/nio/channels/Channels java/nio/channels/DatagramChannel java/nio/channels/spi java/security/cert java/security/Provider java/text java/util/jar java/util/zip java/util/Array java/util/BitSet java/util/Collection java/util/List javax/crypto/Cipher javax/imageio javax/management/openmbean javax/naming javax/rmi javax/sound sun/net/www/protocol sun/misc sun/nio sun/rmi sun/security/pkcs11 sun/security/rsa sun/security/util sun/security/x509 sun/util
++samejvmsafe=com/sun/crypto com/sun/management com/sun/media com/sun/security java/beans/beancontext java/beans/PropertyChangeSupport java/beans/Statement java/beans/VetoableChangeSupport java/lang/Boolean java/lang/Byte java/lang/Double java/lang/Float java/lang/Integer java/lang/Long java/lang/Short java/lang/Math java/lang/StrictMath java/lang/String java/lang/Throwable java/lang/instrument java/math java/net/URI java/net/URLDecoder java/net/URLEncoder java/nio/Buffer java/nio/ByteOrder java/nio/MappedByteBuffer java/nio/channels/Channels java/nio/channels/DatagramChannel java/nio/channels/spi java/security/cert java/security/Provider java/text java/util/jar java/util/zip java/util/Array java/util/BitSet java/util/Collection java/util/List javax/imageio javax/management/openmbean javax/rmi javax/sound sun/net/www/protocol sun/misc sun/nio sun/security/pkcs11 sun/security/rsa sun/util


From mark at klomp.org  Sat Jan 17 09:41:42 2009
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 17 Jan 2009 18:41:42 +0100
Subject: [patch] Less samevm
Message-ID: <1232214102.3713.182.camel@hermans.wildebeest.org>

Hi,

Matthias noticed a couple of tests that do fail if run under samevm (if
you would run them with only the tests in the same dir they succeed, but
when run together with all the tests they fail). I have removed those
from the whitelist. But a better change might be to explicitly mark them
as /othervm.

2009-01-17  Mark Wielaard  <mark at klomp.org>

    * patches/icedtea-version.patch (samejvmsafe): Removed the following
    directories that contain test that are not samevm safe.
    javax/crypto/Cipher (TestGetInstance)
    javax/naming (CompareToEqualsTests)
    sun/rmi (RmicDefault)
    sun/security/util (OidFormat)
    sun/security/x509
    (ExtensibleAlgorithmId,EmailAddressEncoding,AllAttribs)

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samejvm.patch
Type: text/x-patch
Size: 2300 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090117/2bcf86a8/attachment.bin 

From mark at klomp.org  Sat Jan 17 10:07:28 2009
From: mark at klomp.org (Mark Wielaard)
Date: Sat, 17 Jan 2009 19:07:28 +0100
Subject: Public open specs
In-Reply-To: <497073AB.1010302@Sun.COM>
References: <20080917084136.GA10250@bamboo.destinee.acro.gen.nz>
	<1226579378.4563.15.camel@dijkstra.wildebeest.org>
	<491C9E25.6050301@sun.com>
	<1226614223.10363.4.camel@hermans.wildebeest.org>
	<491CAD1C.8040106@sun.com>
	<1226619088.5290.4.camel@dijkstra.wildebeest.org>
	<491D858C.70109@sun.com>
	<1226674908.3266.58.camel@dijkstra.wildebeest.org>
	<491DC160.4030004@sun.com>
	<1226739682.16426.29.camel@hermans.wildebeest.org>
	<17c6771e0811151650g798290b3t7f76f78bb463442b@mail.gmail.com>
	<49219AF0.6070407@sun.com>
	<1228736965.3712.14.camel@dijkstra.wildebeest.org>
	<493D1250.7090007@Sun.COM>
	<1232066791.3379.61.camel@hermans.wildebeest.org>
	<497073AB.1010302@Sun.COM>
Message-ID: <1232215648.3709.11.camel@hermans.wildebeest.org>

Hi Dalibor,

On Fri, 2009-01-16 at 12:46 +0100, Dalibor Topic wrote: 
> On 01/16/09 01:46, Mark Wielaard wrote:
> > Hi Dalibor,
> > Hope you had a great and productive time at Devoxx. 
> Yes, thanks you!

Maybe we can try that again at Fosdem then!

> The discussions were brief. There is no timeline, since there is no 
> decision made by
> Sun to do it - I'm looking at your idea on my own in order to figure out how
> (and when) to make a good case for it.

I think approaching the spec leads directly might be best. After making
sure Sun feels comfortable with the general idea of course. 

> Changing anything regarding the JCP is a massive, politically 
> challenging process -

Yes, but lets concentrate on the specs for which Sun is the spec lead
and owns the copyright, so they can determine themselves how to publish.
Changing the JCP as a whole is a worthy goal, but might be a bit more
work.

> looking at the amount of  work it would potentially take to do what you 
> want for about a dozen of already released JSRs

Agreed, lets chop up the list and go for the JSRs that are in
development for OpenJDK7 first. IMHO those are the most urgent.

So that would be:

JSR 203: More New I/O APIs for the JavaTM Platform ("NIO.2")
(Alan Bateman)
JSR 277: Java Module System
(But Mark Reinhold will probably want to push chainsaw instead)
JSR 292: Supporting Dynamically Typed Languages on the Java Platform
(John Rose)
JSR 294: Improved Modularity Support in the Java Programming Language
(Alex Buckley - who will attend Fosdem, so lets corner him :)

With all spec leads active in some way in OpenJDK, so hopefully they
will be receptive.

With the others being important for OpenJDK6, but seeing that the code
at least is already out there, less of a problem for the work moving
forward (except of course in the case we might find bugs in the code
that might have implications for spec clarification, but we can handle
those cases when they come up).

JSR 105: XML Digital Signature APIs
JSR 199: Java Compiler API
JSR 202: JavaTM Class File Specification Update
JSR 221: JDBC 4.0 API Specification
JSR 222: Java Architecture for XML Binding (JAXB) 2.0
JSR 223: Scripting for the Java Platform
JSR 224: Java API for XML-Based Web Services (JAX-WS) 2.0
JSR 250: Common Annotations for the Java Platform
JSR 255: Java Management Extensions (JMX) Specification, version 2.0
JSR 269: Pluggable Annotation Processing API
JSR 270: Java SE 6 Release Contents

Cheers,

Mark



From matthew.flaschen at gatech.edu  Sat Jan 17 16:14:34 2009
From: matthew.flaschen at gatech.edu (Matthew Flaschen)
Date: Sat, 17 Jan 2009 19:14:34 -0500
Subject: Public open specs
In-Reply-To: <1232215648.3709.11.camel@hermans.wildebeest.org>
References: <20080917084136.GA10250@bamboo.destinee.acro.gen.nz>	<1226579378.4563.15.camel@dijkstra.wildebeest.org>	<491C9E25.6050301@sun.com>	<1226614223.10363.4.camel@hermans.wildebeest.org>	<491CAD1C.8040106@sun.com>	<1226619088.5290.4.camel@dijkstra.wildebeest.org>	<491D858C.70109@sun.com>	<1226674908.3266.58.camel@dijkstra.wildebeest.org>	<491DC160.4030004@sun.com>	<1226739682.16426.29.camel@hermans.wildebeest.org>	<17c6771e0811151650g798290b3t7f76f78bb463442b@mail.gmail.com>	<49219AF0.6070407@sun.com>	<1228736965.3712.14.camel@dijkstra.wildebeest.org>	<493D1250.7090007@Sun.COM>	<1232066791.3379.61.camel@hermans.wildebeest.org>	<497073AB.1010302@Sun.COM>
	<1232215648.3709.11.camel@hermans.wildebeest.org>
Message-ID: <4972746A.80107@gatech.edu>

Mark Wielaard wrote:
> I think approaching the spec leads directly might be best. After making
> sure Sun feels comfortable with the general idea of course. 

There's really no reason to approach the spec leads, except perhaps
courtesy.  Sun owns copyright for all (relevant) work by their
employees, so they can do all their specs with a stroke of a pen we
persuade them.

Matt Flaschen


From doko at ubuntu.com  Sun Jan 18 02:32:43 2009
From: doko at ubuntu.com (Matthias Klose)
Date: Sun, 18 Jan 2009 11:32:43 +0100
Subject: [patch] Less samevm
In-Reply-To: <1232214102.3713.182.camel@hermans.wildebeest.org>
References: <1232214102.3713.182.camel@hermans.wildebeest.org>
Message-ID: <4973054B.8000609@ubuntu.com>

Mark Wielaard schrieb:
> Hi,
> 
> Matthias noticed a couple of tests that do fail if run under samevm (if
> you would run them with only the tests in the same dir they succeed, but
> when run together with all the tests they fail). I have removed those
> from the whitelist. But a better change might be to explicitly mark them
> as /othervm.
> 
> 2009-01-17  Mark Wielaard  <mark at klomp.org>
> 
>     * patches/icedtea-version.patch (samejvmsafe): Removed the following
>     directories that contain test that are not samevm safe.
>     javax/crypto/Cipher (TestGetInstance)
>     javax/naming (CompareToEqualsTests)
>     sun/rmi (RmicDefault)
>     sun/security/util (OidFormat)
>     sun/security/x509
>     (ExtensibleAlgorithmId,EmailAddressEncoding,AllAttribs)

see the failing test cases attached. Please note that
sun/security/util/Oid/OidFormat.java,
sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java,
sun/security/x509/AVA/EmailAddressEncoding.java,
sun/security/x509/X500Name/AllAttribs.java all fail when run without samevm,
they succeed when run with samevm.

  Matthias

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: check-new-vs-same-vm.diff
Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090118/c354d6b7/attachment.ksh 

From bugzilla-daemon at icedtea.classpath.org  Sun Jan 18 05:51:15 2009
From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org)
Date: Sun, 18 Jan 2009 13:51:15 +0000
Subject: [Bug 255] label display in swing ui elements needs (inappropriate)
	additional vertical space
Message-ID: <E1LOY3X-0002PU-B2@icedtea.classpath.org>

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=255


doko at ubuntu.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #6 from doko at ubuntu.com  2009-01-18 13:51 -------
fixed.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


From ekrichardson at gmail.com  Sun Jan 18 18:15:09 2009
From: ekrichardson at gmail.com (Eric Richardson)
Date: Sun, 18 Jan 2009 18:15:09 -0800
Subject: IcedTea Bootstrap Process
In-Reply-To: <17c6771e0901162014x149d29aes8f7a76595b74e2a1@mail.gmail.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>
	<17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>
	<860cb0120901141627m5cf7fdeke99ed7e111113e56@mail.gmail.com>
	<17c6771e0901141657o7d717a52i621c9a0b25f2a666@mail.gmail.com>
	<4970A1A0.4030603@intricatesoftware.com>
	<17c6771e0901161159s1e1b0d83lb861b699f83246dc@mail.gmail.com>
	<4971053C.50609@intricatesoftware.com>
	<17c6771e0901162014x149d29aes8f7a76595b74e2a1@mail.gmail.com>
Message-ID: <860cb0120901181815y49ef8eabh491f5c92d325259b@mail.gmail.com>

On Fri, Jan 16, 2009 at 8:14 PM, Andrew John Hughes <
gnu_andrew at member.fsf.org> wrote:

> 2009/1/16 Kurt Miller <kurt at intricatesoftware.com>:
> > Andrew John Hughes wrote:
> >> 2009/1/16 Kurt Miller <kurt at intricatesoftware.com>:
> >>> Hello Andrew,
> >>>
> >>> Andrew John Hughes wrote:
> >>>> 2009/1/15 Eric Richardson <ekrichardson at gmail.com>:
> >>>>> 2. It seems that there are tons of makefile changes and such brewing
> on the
> >>>>> bsd-ports list that might help us on Mac OS X. What is the mechanism
> for
> >>>>> these to flow into Icedtea?
> >>>>>
> >>>> There isn't one at present.  I think it makes a lot of sense to
> >>>> support *BSD in IcedTea proper (including 6).  CCing to the BSD
> >>>> developers to see if they have any thoughts on this.
> >>> Basically it comes down to lack of resources. If I could work full time
> >>> on bsd-java many things could be considered like merging our work. With
> >>> the available time I have I would like to work towards getting bsd
> >>> support included in the main tree.
> >>>
> >>
> >> I see your point and agree whole-heartedly.  The issue is that there
> >> are in effect two main trees: the OpenJDK6 tree (which is being used,
> >> patched by IcedTea6, in many GNU/Linux distributions) and the OpenJDK7
> >> tree which the BSD tree is currently pulling from.  The problem with 7
> >> is that, while it gets a lot more TLC from Sun, it could be a couple
> >> of years before we see 7 replacing 6 for users and this ties BSD
> >> support to the same timeline.  For me, it would be nice to see *BSD
> >> support sooner than that.
> >
> > True. At some point we will get to OpenJDK6 too. For now I'm following
> > the standard practice of following current/HEAD/tip to increase the
> > likelihood of our work making it in the main tree. If it turns out that
> > Sun isn't interested in merging BSD support into the main tree I would
> > expect that we will change our focus to OpenJDK6.
> >
>
> Fair enough.  I'm not aware of the current situation on *BSD at the
> moment, but I would assume that if an implementation is needed, 6
> would be the one to go for as has happened with the GNU/Linux distros
> (who understandably want to ship a certifiable complete implementation
> not a JDK with no specification as yet).


My original thought was similar, with BSD support and Zero we could get a
JDK 6 to MacOSX on PowerPC. I don't believe Apple plans to support the older
PowerPC platform with a 6 implementation.


>
>
> >> Has there been any thought about support from the various BSD
> >> distributions and the Free stuff that runs on top of Mac OS X?
> >
> > I'm open to any/all support that would allow me to work on open source
> > Java full time. I've not approached Apple or the FreeBSD Foundation
> > though. I know from past experience the FreeBSD Foundation prefers
> > to spend its $ on the certification process and looks to the community
> > for the rest of the heavy lifting. I don't have any contacts at Apple
> > so I wouldn't know where to start in attempting to approach them with
> > the idea.
> >
>
> Well the OpenJDK6 TCK process doesn't cost, though it is effectively a
> self-certification process.  In the same way that RedHat has, you
> and/or FreeBSD could work with the IcedTea community and certify
> resulting binaries.
>
> As to Mac OS X, I wasn't thinking of Apple, but the projects like
> Mac/DarwinPorts and fink that exist to provide FOSS packages.


This is an excellent idea.


>
> >>> I'm not sure you know this but I've been working on bsd java support
> >>> with Sun's JVM for about five years and Greg a few years more then
> that.
> >>> We have merged and merged and merged our work countless times as the
> JDK
> >>> has moved forward. There are about 250 individual files that are
> patched
> >>> to add bsd support. Getting these into the main tree would save us
> >>> countless hours of future merging and free us to work on improving the
> >>> port with our open-source time.
> >>
> >> Yes I am aware of this and I'd also like to see things change.
> >> However, I'm not sure getting it into the OpenJDK7 tree would help
> >> anything, unless Sun are also intending to test and ship their own
> >> binaries for BSD platforms.
> >
> > I wasn't thinking Sun would embrace supporting all the BSD's officially
> > with certified tested binaries. If that happened I would be pleasantly
> > surprised and happy. However, getting our work into the main tree would
> > help us keep up to date and reduce the mundane time of syncing our work
> > at intervals.
> >
> > In any case, predicting how things will play out doesn't serve much
> > purpose. For now I'm content working at refining our tree to the point
> > where a merge could happen.
> >
>
> Sorry, I'm not trying to attack your methods here. It's simply my
> impression that Sun may be against maintaining something in the main
> tree they don't support, but you probably have a better idea of the
> likelihood of it happening.
>
> >>
> >>>>> 3. Are there some simple tasks I can do such as patch diffs or
> something on
> >>>>> patches that won't apply?
> >>>>>
> >>>> You'll need to do that locally.  I'm not sure how much help
> >>>> contributing these back will be until we know how to proceed with
> >>>> this, especially as some will just be because the BSD tree is some old
> >>>> OpenJDK7 version.
> >>> Actually the bsd-port tree is not old, I'm not sure why you thought
> that.
> >>>
> >>
> >> Sorry, I should have been clearer.  I haven't looked at the BSD tree
> >> myself but the problems Eric was seeing suggest that the sources he's
> >> using from the BSD tree are either outdated or have changed for the
> >> BSD port, causing the patches to not apply.  In reality, the cause for
> >> each patch may be one of these or even both.
> >
> > I haven't been following those threads too closely. It looks like he
> > is hitting conflicts due to IcedTea trying to patch files that we needed
> > to change to add BSD support.
> >
>
> Yes, that's what I'm thinking too.
>
> > Its been a while since I looked at IcedTea closely. The last time was
> > probably six months ago. IIRC back then only a RedHat branch of gcc 4.3
> > contained the changes needed to build IcedTea. Is that still the case or
> > has the gcc/gcj support been merged into gcc mainline?
> >
>
> It was a RedHat backport to 4.1 that was required, prior to the
> release of 4.3.  Now 4.3 is available, normal GCC/GCJ can be used.
> It's also possible to use another Classpath VM, but you obviously need
> some way of bootstrapping.  The advantage of gcj is a Java
> implementation is not needed to build.
>
> > Regards,
> > -Kurt
> >
>
> Thanks,
> --
> Andrew :-)
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090118/9d3e7f18/attachment.html 

From gnu_andrew at member.fsf.org  Sun Jan 18 18:29:54 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 19 Jan 2009 02:29:54 +0000
Subject: changeset in /hg/icedtea: Bump to b43.
Message-ID: <hg.bdb64f82284d.1232332194.-6899778133799504387@icedtea.classpath.org>

changeset bdb64f82284d in /hg/icedtea
details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=bdb64f82284d
description:
	Bump to b43.

	2009-01-18  Andrew John Hughes  <gnu_andrew at member.fsf.org>

		Bump to b43.
		* patches/icedtea-6761856-freetypescaler.patch,
		* patches/icedtea-display-mode-changer.patch:
		Removed, applied in b43.
		* ChangeLog: Fix date on last entry.
		* HACKING: Updated list of ecj patches and removed
		dropped patches for IcedTea7.
		* Makefile.am: Remove dropped patches, add new one.
		* patches/ecj/icedtea-sbcs.patch: New patch to prevent
		GenerateSBCS.java using java.util.Scanner for ecj builds.
		* patches/xrender/icedtea-002.patch: Recreated against b43.

diffstat:

7 files changed, 1436 insertions(+), 1572 deletions(-)
ChangeLog                                    |   16 
HACKING                                      |   16 
Makefile.am                                  |   11 
patches/ecj/icedtea-sbcs.patch               |   38 
patches/icedtea-6761856-freetypescaler.patch |   47 
patches/icedtea-display-mode-changer.patch   |  100 
patches/xrender/icedtea-002.patch            | 2780 ++++++++++++--------------

diffs (truncated from 4064 to 500 lines):

diff -r b5fe6c65b574 -r bdb64f82284d ChangeLog
--- a/ChangeLog	Sun Dec 21 05:05:35 2008 +0000
+++ b/ChangeLog	Mon Jan 19 02:29:32 2009 +0000
@@ -1,4 +1,18 @@ 2008-12-20  Andrew John Hughes  <gnu_and
-2008-12-20  Andrew John Hughes  <gnu_andrew at member.fsf.org>
+2009-01-18  Andrew John Hughes  <gnu_andrew at member.fsf.org>
+
+	Bump to b43.
+	* patches/icedtea-6761856-freetypescaler.patch,
+	* patches/icedtea-display-mode-changer.patch:
+	Removed, applied in b43.
+	* ChangeLog: Fix date on last entry.
+	* HACKING: Updated list of ecj patches and removed
+	dropped patches for IcedTea7.
+	* Makefile.am: Remove dropped patches, add new one.
+	* patches/ecj/icedtea-sbcs.patch: New patch to prevent
+	GenerateSBCS.java using java.util.Scanner for ecj builds.
+	* patches/xrender/icedtea-002.patch: Recreated against b43.
+
+2008-12-22  Andrew John Hughes  <gnu_andrew at member.fsf.org>
 
 	* Makefile.am: Fix b42 tarball name and checksum
 	due to reroll.
diff -r b5fe6c65b574 -r bdb64f82284d HACKING
--- a/HACKING	Sun Dec 21 05:05:35 2008 +0000
+++ b/HACKING	Mon Jan 19 02:29:32 2009 +0000
@@ -71,9 +71,6 @@ The following patches are currently appl
 * icedtea-linker-libs-order.patch: When linking, put the referenced libraries after the object files (PR237).
 * icedtea-f2i-overflow.patch: Replaces the code used by [fd]2[il] bytecodes to correctly handle overflows. (PR244)
 * icedtea-cc-interp-no-fer.patch: Report that we cannot force early returns with the C++ interpreter.
-* icedtea-6761856-freetypescaler.patch: Fix IcedTea bug #227, OpenJDK bug
-  #6761856, swing TextLayout.getBounds() returns shifted bounds.
-* icedtea-display-mode-changer.patch: Add extra test class.
 * icedtea-testenv.patch: Provide public reachable machines for net/nio tests.
 * icedtea-samejvm-safe.patch: Add samejvmsafe dirs to TEST.ROOT.
 * icedtea-6728542-epoll.patch: Make EPoll work on non-x86 platforms. (PR265)
@@ -83,6 +80,7 @@ The following patches are only applied t
 The following patches are only applied to OpenJDK6 in IcedTea6:
 
 * icedtea-corba.patch: Adds additional files to org.omg.CORBA Makefile.
+* icedtea-display-mode-changer.patch: Add extra test class. (applied in OpenJDK7 b43)
 * icedtea-gcc-4.3.patch: Fix code to compile with GCC 4.3 and turn off -Werror.
 * icedtea-generated.patch: Force use of /bin/bash.
 * icedtea-nomotif.patch: Remove sanity and GrabShell.h dependency on Motif/Lesstif library.
@@ -92,6 +90,8 @@ The following patches are only applied t
 * icedtea-lucene-crash.patch: Fix lucene bad code generation bug #6707044.
 * icedtea-6700047-loopopts.patch: Fix partial peeling issue, bug #6700047.
 * icedtea-6712835-ifnode.patch: Fix infinite loop in PhaseIterGVN::transform.
+* icedtea-6761856-freetypescaler.patch: Fix IcedTea bug #227, OpenJDK bug
+  #6761856, swing TextLayout.getBounds() returns shifted bounds (applied in OpenJDK7 b43).
 * icedtea-timerqueue.patch: Fix setting of running variable (PR87/S6623943).
 * icedtea-version.patch: Fix (langtools) ant build to honor fcs MILESTONE setting (S6778493).
 
@@ -111,13 +111,19 @@ The following patches are only applied t
 
 The following patches are only applied to the icedtea-ecj bootstrap tree:
 
-* icedtea-ecj.patch: Don't generate CORBA sources using MC/idlj, link against -lgcj
+* ecj/icedtea.patch: Don't generate CORBA sources using MC/idlj, link against -lgcj
   instead of -ljava, force use of boot tools, don't run HotSpot's test_gamma, use
   javac executable with Ant, remove -Werror from javac call, don't build JDK demos,
   don't run sun.awt.X11.ToBin, explicitly pull in timezone data and rt.jar in javac
   calls, replace hexadecimal floating point literals with decimal variants in
   java.lang.Double and java.lang.Float.
-* icedtea-ecj-pr261.patch: Adds a couple of classes that are omitted from rt.jar. (PR261)
+* ecj/icedtea-jopt.patch: Disable -J options to jar when unsupported.
+* ecj/icedtea-pr261.patch: Adds a couple of classes that are omitted from rt.jar. (PR261)
+* ecj/icedtea-spp.patch: Fixes Spp.java to not use java.util.Scanner.
+
+The following patches are only applied to the icedtea-ecj bootstrap tree in IcedTea:
+
+* ecj/icedtea-sbcs.patch: Fixes GenerateSBCS.java to not use java.util.Scanner.
 
 The following patches are only applied for IcedTea builds using the zero-assembler:
 
diff -r b5fe6c65b574 -r bdb64f82284d Makefile.am
--- a/Makefile.am	Sun Dec 21 05:05:35 2008 +0000
+++ b/Makefile.am	Mon Jan 19 02:29:32 2009 +0000
@@ -1,6 +1,6 @@ OPENJDK_DATE = 19_dec_2008
-OPENJDK_DATE = 19_dec_2008
-OPENJDK_MD5SUM = 89eb28aaa3e89e9350f15e5e4b718a40
-OPENJDK_VERSION = b42
+OPENJDK_DATE = 15_jan_2009
+OPENJDK_MD5SUM = 71d680eab0a8e82ba6a76f66322ff2ab
+OPENJDK_VERSION = b43
 
 CACAO_VERSION = 0.99.3
 CACAO_MD5SUM = 80de3ad344c1a20c086ec5f1390bd1b8
@@ -1870,8 +1870,6 @@ ICEDTEA_PATCHES = \
 	patches/icedtea-linker-libs-order.patch \
 	patches/icedtea-f2i-overflow.patch \
 	patches/icedtea-cc-interp-no-fer.patch \
-	patches/icedtea-6761856-freetypescaler.patch \
-	patches/icedtea-display-mode-changer.patch \
 	patches/icedtea-testenv.patch \
 	patches/icedtea-format-warnings.patch \
 	patches/icedtea-fortify-source.patch \
@@ -2198,7 +2196,8 @@ ICEDTEA_ECJ_PATCHES = patches/ecj/icedte
 	patches/ecj/icedtea-hotspot-$(HSBUILD).patch \
 	patches/ecj/icedtea-spp.patch \
 	patches/ecj/icedtea-jopt.patch \
-	patches/ecj/icedtea-pr261.patch
+	patches/ecj/icedtea-pr261.patch \
+	patches/ecj/icedtea-sbcs.patch
 
 stamps/patch-ecj.stamp: stamps/clone-ecj.stamp
 	mkdir -p stamps; \
diff -r b5fe6c65b574 -r bdb64f82284d patches/ecj/icedtea-sbcs.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/ecj/icedtea-sbcs.patch	Mon Jan 19 02:29:32 2009 +0000
@@ -0,0 +1,38 @@
+diff -Nru openjdk-ecj.orig/jdk/make/tools/src/build/tools/charsetmapping/GenerateSBCS.java openjdk-ecj/jdk/make/tools/src/build/tools/charsetmapping/GenerateSBCS.java
+--- openjdk-ecj.orig/jdk/make/tools/src/build/tools/charsetmapping/GenerateSBCS.java	2009-01-18 03:30:42.000000000 +0000
++++ openjdk-ecj/jdk/make/tools/src/build/tools/charsetmapping/GenerateSBCS.java	2009-01-19 00:55:58.000000000 +0000
+@@ -27,7 +27,6 @@
+ 
+ import java.io.*;
+ import java.util.ArrayList;
+-import java.util.Scanner;
+ import java.util.Formatter;
+ import java.util.regex.*;
+ import java.nio.charset.*;
+@@ -40,9 +39,8 @@
+             System.exit(1);
+         }
+ 
+-        Scanner s = new Scanner(new File(args[0], args[2]));
+-        while (s.hasNextLine()) {
+-            String line = s.nextLine();
++        BufferedReader s = new BufferedReader(new FileReader(new File(args[0], args[2])));
++        for (String line = s.readLine(); line != null; line = s.readLine()) {
+             if (line.startsWith("#") || line.length() == 0)
+                 continue;
+             String[] fields = line.split("\\s+");
+@@ -201,12 +199,10 @@
+                                      int    c2blen)
+         throws Exception
+     {
+-        Scanner s = new Scanner(new File(srcDir, template));
++      BufferedReader s = new BufferedReader(new FileReader(new File(srcDir, template)));
+         PrintStream out = new PrintStream(new FileOutputStream(
+                               new File(dstDir, clzName + ".java")));
+-
+-        while (s.hasNextLine()) {
+-            String line = s.nextLine();
++        for (String line = s.readLine(); line != null; line = s.readLine()) {
+             int i = line.indexOf("$");
+             if (i == -1) {
+                 out.println(line);
diff -r b5fe6c65b574 -r bdb64f82284d patches/icedtea-6761856-freetypescaler.patch
--- a/patches/icedtea-6761856-freetypescaler.patch	Sun Dec 21 05:05:35 2008 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,47 +0,0 @@
-# User igor
-# Date 1225234342 -10800
-# Node ID 9cdababf6179bd03270d881740fbb5dcc405854f
-# Parent 594c52582b21063bdbc36b38d9f73a3c46abe041
-6761856: OpenJDK: vertical text metrics may be significanly different from those returned by Sun JDK
-Reviewed-by: bae, prr
-
---- openjdk.orig/jdk/src/share/native/sun/font/freetypeScaler.c	Tue Oct 28 14:47:14 2008 -0700
-+++ openjdk/jdk/src/share/native/sun/font/freetypeScaler.c	Wed Oct 29 01:52:22 2008 +0300
-@@ -1281,7 +1281,7 @@ Java_sun_font_FreetypeFontScaler_getGlyp
-                                    sunFontIDs.rect2DFloatClass,
-                                    sunFontIDs.rect2DFloatCtr4,
-                                    F26Dot6ToFloat(bbox.xMin),
--                                   F26Dot6ToFloat(bbox.yMax),
-+                                   F26Dot6ToFloat(-bbox.yMax),
-                                    F26Dot6ToFloat(bbox.xMax-bbox.xMin),
-                                    F26Dot6ToFloat(bbox.yMax-bbox.yMin));
-     }
---- openjdk.orig/jdk/test/java/awt/font/TextLayout/TextLayoutBounds.java	Tue Oct 28 14:47:14 2008 -0700
-+++ openjdk/jdk/test/java/awt/font/TextLayout/TextLayoutBounds.java	Wed Oct 29 01:52:22 2008 +0300
-@@ -22,7 +22,7 @@
-  */
- /* @test
-  * @summary verify TextLayout.getBounds() return visual bounds
-- * @bug 6323611
-+ * @bug 6323611 6761856
-  */
- 
- import java.awt.*;
-@@ -39,10 +39,15 @@ public class TextLayoutBounds {
-        Rectangle2D tlBounds = tl.getBounds();
-        GlyphVector gv = f.createGlyphVector(frc, s);
-        Rectangle2D gvvBounds = gv.getVisualBounds();
-+       Rectangle2D oBounds = tl.getOutline(null).getBounds2D();
-        System.out.println("tlbounds="+tlBounds);
-        System.out.println("gvbounds="+gvvBounds);
-+       System.out.println("outlineBounds="+oBounds);
-        if (!gvvBounds.equals(tlBounds)) {
--          throw new RuntimeException("Bounds differ");
-+          throw new RuntimeException("Bounds differ [gvv != tl]");
-+       }
-+       if (!tlBounds.equals(oBounds)) {
-+          throw new RuntimeException("Bounds differ [tl != outline]");
-        }
-     }
- }
-
diff -r b5fe6c65b574 -r bdb64f82284d patches/icedtea-display-mode-changer.patch
--- a/patches/icedtea-display-mode-changer.patch	Sun Dec 21 05:05:35 2008 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,100 +0,0 @@
-6733718: test /java/awt/FullScreen/UninitializedDisplayModeChangeTest/ fails
-Reviewed-by: igor
-
---- /dev/null	Thu Jan 01 00:00:00 1970 +0000
-+++ openjdk/jdk/test/java/awt/FullScreen/UninitializedDisplayModeChangeTest/DisplayModeChanger.java	Tue Aug 05 09:37:03 2008 -0700
-@@ -0,0 +1,93 @@
-+/*
-+ * Copyright 2006-2008 Sun Microsystems, Inc.  All Rights Reserved.
-+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
-+ *
-+ * This code is free software; you can redistribute it and/or modify it
-+ * under the terms of the GNU General Public License version 2 only, as
-+ * published by the Free Software Foundation.
-+ *
-+ * This code is distributed in the hope that it will be useful, but WITHOUT
-+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-+ * version 2 for more details (a copy is included in the LICENSE file that
-+ * accompanied this code).
-+ *
-+ * You should have received a copy of the GNU General Public License version
-+ * 2 along with this work; if not, write to the Free Software Foundation,
-+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
-+ *
-+ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
-+ * CA 95054 USA or visit www.sun.com if you need additional information or
-+ * have any questions.
-+ */
-+
-+import java.awt.DisplayMode;
-+import java.awt.EventQueue;
-+import java.awt.Frame;
-+import java.awt.GraphicsDevice;
-+import java.awt.GraphicsEnvironment;
-+import java.lang.reflect.InvocationTargetException;
-+
-+/**
-+ * Used by the UninitializedDisplayModeChangeTest to change the
-+ * display mode.
-+ */
-+public class DisplayModeChanger {
-+
-+    public static void main(String[] args)
-+        throws InterruptedException, InvocationTargetException
-+    {
-+        final GraphicsDevice gd =
-+            GraphicsEnvironment.getLocalGraphicsEnvironment().
-+                getDefaultScreenDevice();
-+
-+        EventQueue.invokeAndWait(new Runnable() {
-+            public void run() {
-+                Frame f = null;
-+                if (gd.isFullScreenSupported()) {
-+                    try {
-+                        f = new Frame("DisplayChanger Frame");
-+                        gd.setFullScreenWindow(f);
-+                        if (gd.isDisplayChangeSupported()) {
-+                            DisplayMode dm = findDisplayMode(gd);
-+                            if (gd != null) {
-+                                gd.setDisplayMode(dm);
-+                            }
-+                        }
-+                        try {
-+                            Thread.sleep(1000);
-+                        } catch (InterruptedException ex) {
-+                            ex.printStackTrace();
-+                        }
-+                        gd.setFullScreenWindow(null);
-+                    } finally {
-+                        if (f != null) {
-+                            f.dispose();
-+                        }
-+                    }
-+                }
-+            }
-+        });
-+    }
-+
-+    /**
-+     * Finds a display mode that is different from the current display
-+     * mode and is likely to cause a display change event.
-+     */
-+    private static DisplayMode findDisplayMode(GraphicsDevice gd) {
-+        DisplayMode dms[] = gd.getDisplayModes();
-+        DisplayMode currentDM = gd.getDisplayMode();
-+        for (DisplayMode dm : dms) {
-+            if (!dm.equals(currentDM) &&
-+                 dm.getRefreshRate() == currentDM.getRefreshRate())
-+            {
-+                // different from the current dm and refresh rate is the same
-+                // means that something else is different => more likely to
-+                // cause a DM change event
-+                return dm;
-+            }
-+        }
-+        return null;
-+    }
-+
-+}
-
diff -r b5fe6c65b574 -r bdb64f82284d patches/xrender/icedtea-002.patch
--- a/patches/xrender/icedtea-002.patch	Sun Dec 21 05:05:35 2008 +0000
+++ b/patches/xrender/icedtea-002.patch	Mon Jan 19 02:29:32 2009 +0000
@@ -1,13 +1,6 @@
-# HG changeset patch
-# User ceisserer
-# Date 1217623431 -7200
-# Node ID 4b11af86e814b7d62e9e1e19788d527987bb209c
-# Parent  6d294fa2bd421e3c8978730855d7300af692b271
-Summary: Comments, bug fixes, initial solaris work
-
-diff -r 6d294fa2bd42 -r 4b11af86e814 make/sun/xawt/Makefile
---- openjdk/jdk/make/sun/xawt/Makefile	Sat Jul 26 00:13:41 2008 +0200
-+++ openjdk/jdk/make/sun/xawt/Makefile	Fri Aug 01 22:43:51 2008 +0200
+diff -Nru openjdk.orig/jdk/make/sun/xawt/Makefile openjdk/jdk/make/sun/xawt/Makefile
+--- openjdk.orig/jdk/make/sun/xawt/Makefile	2009-01-18 01:30:31.000000000 +0000
++++ openjdk/jdk/make/sun/xawt/Makefile	2009-01-18 01:47:11.000000000 +0000
 @@ -86,7 +86,7 @@
  vpath %.c   $(PLATFORM_SRC)/native/sun/java2d/opengl
  vpath %.c   $(PLATFORM_SRC)/native/sun/java2d/x11
@@ -17,10 +10,10 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 mak
                     $(LDFLAGS_COMMON) $(AWT_RUNPATH) $(OTHER_LDFLAGS) -lXtst -lXi
  
  ifeq  ($(PLATFORM), solaris)
-diff -r 6d294fa2bd42 -r 4b11af86e814 make/sun/xawt/mapfile-vers
---- openjdk/jdk/make/sun/xawt/mapfile-vers	Sat Jul 26 00:13:41 2008 +0200
-+++ openjdk/jdk/make/sun/xawt/mapfile-vers	Fri Aug 01 22:43:51 2008 +0200
-@@ -314,6 +314,15 @@
+diff -Nru openjdk.orig/jdk/make/sun/xawt/mapfile-vers openjdk/jdk/make/sun/xawt/mapfile-vers
+--- openjdk.orig/jdk/make/sun/xawt/mapfile-vers	2009-01-18 01:30:31.000000000 +0000
++++ openjdk/jdk/make/sun/xawt/mapfile-vers	2009-01-18 01:48:17.000000000 +0000
+@@ -316,6 +316,13 @@
          Java_sun_java2d_opengl_GLXSurfaceData_initOps;
          Java_sun_java2d_opengl_GLXSurfaceData_initPbuffer;
  
@@ -29,21 +22,15 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 mak
 +        Java_sun_java2d_x11_XSurfaceData_XResetClip;
 +        Java_sun_java2d_x11_XSurfaceData_XSetClip;
 +        Java_sun_java2d_x11_XSurfaceData_flushNativeSurface;
-+	Java_sun_java2d_x11_XSurfaceData_isDrawableValid;
-+        Java_sun_java2d_x11_XSurfaceData_setInvalid;
 +        Java_sun_java2d_x11_XSurfaceData_XSetGraphicsExposures;
 +
          Java_sun_java2d_x11_X11PMBlitBgLoops_nativeBlitBg;
          Java_sun_java2d_x11_X11PMBlitLoops_nativeBlit;
          Java_sun_java2d_x11_X11PMBlitLoops_updateBitmask;
-@@ -331,20 +340,12 @@
- 	Java_sun_java2d_x11_X11Renderer_XFillRect;
- 	Java_sun_java2d_x11_X11Renderer_XFillRoundRect;
-         Java_sun_java2d_x11_X11Renderer_devCopyArea;
--        Java_sun_java2d_x11_X11SurfaceData_setInvalid;
-         Java_sun_java2d_x11_X11SurfaceData_initIDs;
--	Java_sun_java2d_x11_X11SurfaceData_isDrawableValid;
+@@ -338,16 +345,10 @@
+ 	Java_sun_java2d_x11_X11SurfaceData_isDrawableValid;
          Java_sun_java2d_x11_X11SurfaceData_isDgaAvailable;
+ 	Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable;
 -        Java_sun_java2d_x11_X11SurfaceData_initOps;
          Java_sun_java2d_x11_X11SurfaceData_initSurface;
 -        Java_sun_java2d_x11_X11SurfaceData_flushNativeSurface;
@@ -57,9 +44,9 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 mak
  
          Java_sun_java2d_xr_XRSurfaceData_flushNativeSurface;
          Java_sun_java2d_xr_XRSurfaceData_XRIsDrawableValid;
-diff -r 6d294fa2bd42 -r 4b11af86e814 src/solaris/classes/sun/font/XRTextRenderer.java
---- openjdk/jdk/src/solaris/classes/sun/font/XRTextRenderer.java	Sat Jul 26 00:13:41 2008 +0200
-+++ openjdk/jdk/src/solaris/classes/sun/font/XRTextRenderer.java	Fri Aug 01 22:43:51 2008 +0200
+diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/font/XRTextRenderer.java openjdk/jdk/src/solaris/classes/sun/font/XRTextRenderer.java
+--- openjdk.orig/jdk/src/solaris/classes/sun/font/XRTextRenderer.java	2009-01-18 01:30:31.000000000 +0000
++++ openjdk/jdk/src/solaris/classes/sun/font/XRTextRenderer.java	2009-01-18 01:47:11.000000000 +0000
 @@ -25,7 +25,7 @@
  
  package sun.font;
@@ -109,10 +96,10 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 src
 +		}
 +	}
  }
-diff -r 6d294fa2bd42 -r 4b11af86e814 src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
---- openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java	Sat Jul 26 00:13:41 2008 +0200
-+++ openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java	Fri Aug 01 22:43:51 2008 +0200
-@@ -60,7 +60,7 @@
+diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
+--- openjdk.orig/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java	2009-01-18 01:30:31.000000000 +0000
++++ openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java	2009-01-18 01:47:11.000000000 +0000
+@@ -61,7 +61,7 @@
  import sun.java2d.pipe.TextPipe;
  import sun.java2d.pipe.Region;
  
@@ -121,7 +108,7 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 src
      X11ComponentPeer peer;
      X11GraphicsConfig graphicsConfig;
      private RenderLoops solidloops;
-@@ -70,8 +70,6 @@
+@@ -71,8 +71,6 @@
      private static native void initIDs(Class xorComp, boolean tryDGA);  //OK
      protected native void initSurface(int depth, int width, int height,
                                        long drawable);
@@ -130,7 +117,7 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 src
  
      public static final String
          DESC_INT_BGR_X11        = "Integer BGR Pixmap";
-@@ -405,12 +403,6 @@
+@@ -420,12 +418,6 @@
                                          cm, drawable, transparency);
      }
  
@@ -143,7 +130,7 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 src
      protected X11SurfaceData(X11ComponentPeer peer,
                               X11GraphicsConfig gc,
                               SurfaceType sType,
-@@ -568,8 +560,6 @@
+@@ -583,8 +575,6 @@
          return sType;
      }
  
@@ -152,7 +139,7 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 src
      public void invalidate() {
          if (isValid()) {
              setInvalid();
-@@ -581,18 +571,10 @@
+@@ -596,18 +586,10 @@
       * The following methods and variables are used to keep the Java-level
       * context state in sync with the native X11 GC associated with this
       * X11SurfaceData object.
@@ -172,9 +159,9 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 src
  
      private long xgc;
      private Region validatedClip;
-diff -r 6d294fa2bd42 -r 4b11af86e814 src/solaris/classes/sun/java2d/x11/XSurfaceData.java
---- /dev/null	Thu Jan 01 00:00:00 1970 +0000
-+++ openjdk/jdk/src/solaris/classes/sun/java2d/x11/XSurfaceData.java	Fri Aug 01 22:43:51 2008 +0200
+diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/java2d/x11/XSurfaceData.java openjdk/jdk/src/solaris/classes/sun/java2d/x11/XSurfaceData.java
+--- openjdk.orig/jdk/src/solaris/classes/sun/java2d/x11/XSurfaceData.java	1970-01-01 01:00:00.000000000 +0100
++++ openjdk/jdk/src/solaris/classes/sun/java2d/x11/XSurfaceData.java	2009-01-18 01:47:11.000000000 +0000
 @@ -0,0 +1,35 @@
 +package sun.java2d.x11;
 +
@@ -211,9 +198,9 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 src
 +    protected static native void XSetGraphicsExposures(long xgc,
 +            boolean needExposures);
 +}
-diff -r 6d294fa2bd42 -r 4b11af86e814 src/solaris/classes/sun/java2d/xr/XRDrawImage.java
---- openjdk/jdk/src/solaris/classes/sun/java2d/xr/XRDrawImage.java	Sat Jul 26 00:13:41 2008 +0200
-+++ openjdk/jdk/src/solaris/classes/sun/java2d/xr/XRDrawImage.java	Fri Aug 01 22:43:51 2008 +0200
+diff -Nru openjdk.orig/jdk/src/solaris/classes/sun/java2d/xr/XRDrawImage.java openjdk/jdk/src/solaris/classes/sun/java2d/xr/XRDrawImage.java
+--- openjdk.orig/jdk/src/solaris/classes/sun/java2d/xr/XRDrawImage.java	2009-01-18 01:30:31.000000000 +0000
++++ openjdk/jdk/src/solaris/classes/sun/java2d/xr/XRDrawImage.java	2009-01-18 01:47:11.000000000 +0000
 @@ -7,44 +7,36 @@
  import sun.java2d.loops.*;
  import sun.java2d.pipe.*;
@@ -233,12 +220,7 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 src
 -                                             sg.TRANSFORM_GENERIC,
 -                                             sg.imageComp,
 -                                             bgColor);
-+	    AffineTransform tx, int interpType, int sx1, int sy1, int sx2,
-+	    int sy2, Color bgColor) {
-+	SurfaceData dstData = sg.surfaceData;
-+	SurfaceData srcData = dstData.getSourceSurfaceData(img,
-+		SunGraphics2D.TRANSFORM_GENERIC, sg.imageComp, bgColor);
- 
+-
 -            if (srcData != null && !isBgOperation(srcData, bgColor) && srcData instanceof XRSurfaceData)
 -            {
 -                SurfaceType srcType = srcData.getSurfaceType();
@@ -249,11 +231,7 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 src
 -                TransformBlit blit = TransformBlit.getFromCache(srcType,
 -                                                                sg.imageComp,
 -                                                                dstType);
-+	if (srcData != null && !isBgOperation(srcData, bgColor)
-+		&& srcData instanceof XRSurfaceData) {
-+	    SurfaceType srcType = srcData.getSurfaceType();
-+	    SurfaceType dstType = dstData.getSurfaceType();
- 
+-
 -                if (blit != null) {
 -                    blit.Transform(srcData, dstData,
 -                                   sg.composite, sg.getCompClip(),
@@ -263,10 +241,20 @@ diff -r 6d294fa2bd42 -r 4b11af86e814 src
 -                }
 -       
 -        }
++	    AffineTransform tx, int interpType, int sx1, int sy1, int sx2,
++	    int sy2, Color bgColor) {
++	SurfaceData dstData = sg.surfaceData;
++	SurfaceData srcData = dstData.getSourceSurfaceData(img,
++		SunGraphics2D.TRANSFORM_GENERIC, sg.imageComp, bgColor);
++
++	if (srcData != null && !isBgOperation(srcData, bgColor)
++		&& srcData instanceof XRSurfaceData) {
++	    SurfaceType srcType = srcData.getSurfaceType();
++	    SurfaceType dstType = dstData.getSurfaceType();
++
 +	    ((XRSurfaceData) srcData).setPreferredInterpolation(XRUtils
 +		    .ATransOpToXRQuality(interpType));
- 
--        super.renderImageXform(sg, img, tx, interpType,  sx1, sy1, sx2, sy2, bgColor);


From gbenson at redhat.com  Mon Jan 19 01:17:45 2009
From: gbenson at redhat.com (Gary Benson)
Date: Mon, 19 Jan 2009 09:17:45 +0000
Subject: IcedTea Bootstrap Process
In-Reply-To: <4971053C.50609@intricatesoftware.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>
	<17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>
	<860cb0120901141627m5cf7fdeke99ed7e111113e56@mail.gmail.com>
	<17c6771e0901141657o7d717a52i621c9a0b25f2a666@mail.gmail.com>
	<4970A1A0.4030603@intricatesoftware.com>
	<17c6771e0901161159s1e1b0d83lb861b699f83246dc@mail.gmail.com>
	<4971053C.50609@intricatesoftware.com>
Message-ID: <20090119091744.GA3205@redhat.com>

Kurt Miller wrote:
> True. At some point we will get to OpenJDK6 too. For now I'm
> following the standard practice of following current/HEAD/tip to
> increase the likelihood of our work making it in the main tree. If
> it turns out that Sun isn't interested in merging BSD support into
> the main tree I would expect that we will change our focus to
> OpenJDK6.

How are the BSD changes split between HotSpot and the class library?
I don't know if you know this, but for IcedTea6 we replace the bundled
HotSpot with a much newer version, so we may be working closer to the
main tip than you realise, for HotSpot at least.

Cheers,
Gary

-- 
http://gbenson.net/


From glewis at eyesbeyond.com  Mon Jan 19 09:15:12 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Mon, 19 Jan 2009 09:15:12 -0800
Subject: IcedTea Bootstrap Process
In-Reply-To: <20090119091744.GA3205@redhat.com>
References: <fee4d890901131622k3de75ff5xe2d45cb950b476c9@mail.gmail.com>
	<17c6771e0901132035s2588f275s8a7e8e2997241ed6@mail.gmail.com>
	<860cb0120901141627m5cf7fdeke99ed7e111113e56@mail.gmail.com>
	<17c6771e0901141657o7d717a52i621c9a0b25f2a666@mail.gmail.com>
	<4970A1A0.4030603@intricatesoftware.com>
	<17c6771e0901161159s1e1b0d83lb861b699f83246dc@mail.gmail.com>
	<4971053C.50609@intricatesoftware.com>
	<20090119091744.GA3205@redhat.com>
Message-ID: <20090119171512.GA90423@misty.eyesbeyond.com>

G'day Gary,

On Mon, Jan 19, 2009 at 09:17:45AM +0000, Gary Benson wrote:
> Kurt Miller wrote:
> > True. At some point we will get to OpenJDK6 too. For now I'm
> > following the standard practice of following current/HEAD/tip to
> > increase the likelihood of our work making it in the main tree. If
> > it turns out that Sun isn't interested in merging BSD support into
> > the main tree I would expect that we will change our focus to
> > OpenJDK6.
> 
> How are the BSD changes split between HotSpot and the class library?

The HotSpot changes are more extensive since we need to create a whole
BSD hierarchy to mirror the Linux and Solaris ones.  However, the code
itself is often very similar if not identical to Linux or Solaris.

> I don't know if you know this, but for IcedTea6 we replace the bundled
> HotSpot with a much newer version, so we may be working closer to the
> main tip than you realise, for HotSpot at least.

Yes, I'm aware that IcedTea6 is using HS 14, which is also the version in
use in OpenJDK7.  So in that sense they should apply fairly easily.

The big sticking point here, as Kurt has already mentioned, is time.
I think it would be great to get BSD support into IcedTea, but I'm not
sure that I have time to commit to making it happen.  For me, the main
focus will probably continue to be OpenJDK7 and keeping the BSD port of
that up to date.  That is the minimum bar we need to meet to be able to
get our changes merged into mainline.

Having said that, IcedTea has some benefits, the primary one being the
Zero port which will give us support for extra architectures (all?
of which are supported by at least one BSD variant I believe).  So what
I'd really like to evaluate is how hard that would be to port to BSD.
Where do I need to look at in the IcedTea tree to get a handle on this?
Should I just look at the ppc specific directories in HotSpot?  Presumably
there is also some shared code between the different architectures that
Zero supports though?  Also, what progress has been made getting Zero into
the main OpenJDK7 sources (which is an approved project as I understand
it)?

If its not too hard to port Zero to BSD then porting to IcedTea becomes
more attractive :).

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From dbhole at redhat.com  Mon Jan 19 11:41:20 2009
From: dbhole at redhat.com (Deepak Bhole)
Date: Mon, 19 Jan 2009 19:41:20 +0000
Subject: changeset in /hg/icedtea6: - Fixed a bug in remote->local image ...
Message-ID: <hg.c63cc0eff68b.1232394080.2873452341184383832@icedtea.classpath.org>

changeset c63cc0eff68b in /hg/icedtea6
details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=c63cc0eff68b
description:
	- Fixed a bug in remote->local image url mapping that caused the plugin to
	  hang in some cases

	- Implemented a common interface that is now queried by all security dialogs

	- Implemented a user prompt for untrusted https certificates (WIP)

diffstat:

18 files changed, 679 insertions(+), 95 deletions(-)
ChangeLog                                                      |   34 +
IcedTeaPlugin.cc                                               |    2 
plugin/icedtea/sun/applet/PluginAppletViewer.java              |   12 
plugin/icedtea/sun/applet/PluginMain.java                      |   22 
rt/net/sourceforge/jnlp/runtime/JNLPClassLoader.java           |   34 +
rt/net/sourceforge/jnlp/security/AccessWarningPane.java        |   34 +
rt/net/sourceforge/jnlp/security/AppletWarningPane.java        |    6 
rt/net/sourceforge/jnlp/security/CertWarningPane.java          |   27 -
rt/net/sourceforge/jnlp/security/CertsInfoPane.java            |    4 
rt/net/sourceforge/jnlp/security/HttpsCertVerifier.java        |  119 +++++
rt/net/sourceforge/jnlp/security/MoreInfoPane.java             |   30 -
rt/net/sourceforge/jnlp/security/SecurityDialogUI.java         |   32 -
rt/net/sourceforge/jnlp/security/SecurityWarningDialog.java    |   50 +-
rt/net/sourceforge/jnlp/security/SingleCertInfoPane.java       |    6 
rt/net/sourceforge/jnlp/security/VariableX509TrustManager.java |  222 ++++++++++
rt/net/sourceforge/jnlp/security/viewer/CertificatePane.java   |   18 
rt/net/sourceforge/jnlp/tools/CertVerifier.java                |   92 ++++
rt/net/sourceforge/jnlp/tools/JarSigner.java                   |   30 +

diffs (truncated from 1214 to 500 lines):

diff -r 3a265e06dc74 -r c63cc0eff68b ChangeLog
--- a/ChangeLog	Sat Jan 17 18:41:18 2009 +0100
+++ b/ChangeLog	Mon Jan 19 14:41:10 2009 -0500
@@ -1,3 +1,37 @@ 2009-01-17  Mark Wielaard  <mark at klomp.o
+2009-01-19  Deepak Bhole  <dbhole at redhat.com>
+
+	* IcedTeaPlugin.cc: Add "Java" in the plugin description string. 
+	* plugin/icedtea/sun/applet/PluginAppletViewer.java: Change the way the
+	image was searched locally.
+	* plugin/icedtea/sun/applet/PluginMain.java: Install a custom SSL trust
+	manager.
+	* rt/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: Cache file names
+	from jars.
+	* rt/net/sourceforge/jnlp/security/AccessWarningPane.java: Accept
+	CertVerifier as an additional argument.
+	* rt/net/sourceforge/jnlp/security/AppletWarningPane.java: Same.
+	* rt/net/sourceforge/jnlp/security/CertWarningPane.java: Same.
+	* rt/net/sourceforge/jnlp/security/CertsInfoPane.java: Same.
+	* rt/net/sourceforge/jnlp/security/HttpsCertVerifier.java: New file.
+	Implements information gathering functions used by various prompt dialogs.
+	* rt/net/sourceforge/jnlp/security/MoreInfoPane.java: Accept CertVerifier 
+	as an additional argument.
+	* rt/net/sourceforge/jnlp/security/SecurityDialogUI.java: Same.
+	* rt/net/sourceforge/jnlp/security/SecurityWarningDialog.java: Use the new
+	common CertVerifier interface to gather information.
+	* rt/net/sourceforge/jnlp/security/SingleCertInfoPane.java: Accept
+	CertVerifier as an additional argument.
+	* rt/net/sourceforge/jnlp/security/VariableX509TrustManager.java:
+	Customized trustmanager that can temporarily trust certificates on the
+	fly.
+	* rt/net/sourceforge/jnlp/security/viewer/CertificatePane.java: Accept
+	CertVerifier as an additional argument.
+	* rt/net/sourceforge/jnlp/tools/CertVerifier.java: New common interface
+	that all security related dialogs now query for certificate info (jar and
+	https).
+	* rt/net/sourceforge/jnlp/tools/JarSigner.java: Implement the new
+	CertVerifier verifier interface.
+
 2009-01-17  Mark Wielaard  <mark at klomp.org>
 
 	* patches/icedtea-version.patch (samejvmsafe): Removed the following
diff -r 3a265e06dc74 -r c63cc0eff68b IcedTeaPlugin.cc
--- a/IcedTeaPlugin.cc	Sat Jan 17 18:41:18 2009 +0100
+++ b/IcedTeaPlugin.cc	Mon Jan 19 14:41:10 2009 -0500
@@ -275,7 +275,7 @@ inline long get_time_in_s()
 #define PLUGIN_CHECK(message, result)
 #endif
 
-#define PLUGIN_NAME "IcedTea Web Browser Plugin"
+#define PLUGIN_NAME "IcedTea Java Web Browser Plugin"
 #define PLUGIN_DESCRIPTION "The " PLUGIN_NAME PLUGIN_VERSION " executes Java applets."
 #define PLUGIN_MIME_DESC                                               \
   "application/x-java-vm:class,jar:IcedTea;"                           \
diff -r 3a265e06dc74 -r c63cc0eff68b plugin/icedtea/sun/ap