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 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/bsd-port-dev/attachments/20090102/933de2a1/attachment.html 

From mvfranz at gmail.com  Fri Jan  2 12:05:24 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Fri, 2 Jan 2009 15:05:24 -0500
Subject: Building on Leopard for Tiger (OS X)
Message-ID: <fee4d890901021205u7a4bad6bq18d9890c5d2dffc7@mail.gmail.com>

Hi,

I have been trying to build the BSD port so that I can run it on Tiger, I
have been this technote
http://developer.apple.com/technotes/tn2002/tn2064.html, but am not sure I
all I have to do is pass in the correct parameter to the build.  I have been
passing in MACOSX_DEPLOYMENT_TARGET=10.4 and there is logic in the source
that use MAC_OS_X_VERSION_MAX_ALLOWED.  The problem that I am having is that
the context_pc does not seem to be included correctly when I try to build
for Tiger.

It seems that the internal structure of context changed between Tiger and
Leopard.  Part of this that confuses me is, if I was able to get this to
build, would it actually work on both Tiger and Leopard?  Or would I have to
have two different binaries?  If it would work, why not just build for Tiger
by default?

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090102/14751341/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/bsd-port-dev/attachments/20090102/b910ff63/attachment.html 

From landonf at plausiblelabs.com  Fri Jan  2 13:54:16 2009
From: landonf at plausiblelabs.com (Landon Fuller)
Date: Fri, 2 Jan 2009 13:54:16 -0800
Subject: Building on Leopard for Tiger (OS X)
In-Reply-To: <fee4d890901021205u7a4bad6bq18d9890c5d2dffc7@mail.gmail.com>
References: <fee4d890901021205u7a4bad6bq18d9890c5d2dffc7@mail.gmail.com>
Message-ID: <D386C6BA-1F6D-4BB0-81D5-111F174284BB@plausiblelabs.com>


On Jan 2, 2009, at 12:05 PM, Michael Franz wrote:

> Hi,
>
> I have been trying to build the BSD port so that I can run it on  
> Tiger, I have been this technote http://developer.apple.com/technotes/tn2002/tn2064.html 
> , but am not sure I all I have to do is pass in the correct  
> parameter to the build.  I have been passing in  
> MACOSX_DEPLOYMENT_TARGET=10.4 and there is logic in the source that  
> use MAC_OS_X_VERSION_MAX_ALLOWED.  The problem that I am having is  
> that the context_pc does not seem to be included correctly when I  
> try to build for Tiger.

This may be another error on my part, during my merging of the  
previously distinct amd64/i386 sources.

> It seems that the internal structure of context changed between  
> Tiger and Leopard.  Part of this that confuses me is, if I was able  
> to get this to build, would it actually work on both Tiger and  
> Leopard?  Or would I have to have two different binaries?  If it  
> would work, why not just build for Tiger by default?

A 32-bit build will work on Leopard and Tiger -- this is how I'm  
distributing Soylatte.

Cheers,
Landon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090102/b05a4725/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090102/b05a4725/PGP.sig 

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/bsd-port-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/bsd-port-dev/attachments/20090102/44268040/attachment.html 

From mvfranz at gmail.com  Fri Jan  2 19:59:37 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Fri, 2 Jan 2009 22:59:37 -0500
Subject: Patch to build 64 bit VM
In-Reply-To: <495C475A.1030405@Sun.COM>
References: <4949DC28.6020703@Sun.COM> <494FE536.1040102@Sun.COM>
	<20081226072429.GA69479@misty.eyesbeyond.com> <49548922.80703@Sun.COM>
	<20081226172736.GA42840@misty.eyesbeyond.com>
	<20081228082926.GA77650@misty.eyesbeyond.com>
	<20081228205541.GA11757@misty.eyesbeyond.com>
	<4957F135.3040300@Sun.COM>
	<20081229164706.GA52523@misty.eyesbeyond.com>
	<495C475A.1030405@Sun.COM>
Message-ID: <fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>

Hi,

On Wed, Dec 31, 2008 at 11:32 PM, Xiaobin Lu <Xiaobin.Lu at sun.com> wrote:

> Greg,
>
> I tried to pass in LP64=1 to build 64 bit VM on Mac OS. This is same as
> other platforms. It looks like you have checked in the fix to
> os_bsd_x86.cpp so I don't believe I have to do anything more.
>
> Regards,
>
> Happy new year.
> -Xiaobin
>

I am not sure where this leaves the 64 bit and 32 bit builds, but I cannot
build either without patching them.  I also noticed that the 64 bit builds
does not seem to honor the NO_DOCS=true flag.

make[3]: *** No rule to make target
`/Users/mfranz/developer/openjdk-bsd/repos/2009-01-02/build/bsd-i586/hotspot/import/docs/platform/jvmti/jvmti.html',
needed by `generic_export'

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090102/be04d805/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/bsd-port-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/bsd-port-dev/attachments/20090103/c131ca90/attachment.html 

From Kelly.Ohair at Sun.COM  Sat Jan  3 11:00:11 2009
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Sat, 03 Jan 2009 11:00:11 -0800
Subject: Patch to build 64 bit VM
In-Reply-To: <fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>
References: <4949DC28.6020703@Sun.COM> <494FE536.1040102@Sun.COM>
	<20081226072429.GA69479@misty.eyesbeyond.com> <49548922.80703@Sun.COM>
	<20081226172736.GA42840@misty.eyesbeyond.com>
	<20081228082926.GA77650@misty.eyesbeyond.com>
	<20081228205541.GA11757@misty.eyesbeyond.com>
	<4957F135.3040300@Sun.COM>
	<20081229164706.GA52523@misty.eyesbeyond.com>
	<495C475A.1030405@Sun.COM>
	<fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>
Message-ID: <495FB5BB.9000709@sun.com>

FYI..

The NO_DOCS and jvmti.html have never been related to each other.
The NO_DOCS mostly applied to the javadoc docs in the non-hotspot
repositories, jvmti.html isn't part of the javadoc generated files.

The hotspot jvmti file generation is a bit special. There is a jvmti.xml file
in the hotspot repository that is used to generate hotspot C++ code,
jvmti.h, and jvmti.html (the JVM TI document).
So jvmti.h and jvmti.html are considered 'export' files from builds
of hotspot, along with files like libjvm.so, jni.h, jmm.h, etc.

The jvmti.html file is essentially this file, e.g. jdk6
   http://java.sun.com/javase/6/docs/platform/jvmti/jvmti.html

-kto

Michael Franz wrote:
> Hi,
> 
> On Wed, Dec 31, 2008 at 11:32 PM, Xiaobin Lu <Xiaobin.Lu at sun.com 
> <mailto:Xiaobin.Lu at sun.com>> wrote:
> 
>     Greg,
> 
>     I tried to pass in LP64=1 to build 64 bit VM on Mac OS. This is same as
>     other platforms. It looks like you have checked in the fix to
>     os_bsd_x86.cpp so I don't believe I have to do anything more.
> 
>     Regards,
> 
>     Happy new year.
>     -Xiaobin
> 
> 
> I am not sure where this leaves the 64 bit and 32 bit builds, but I 
> cannot build either without patching them.  I also noticed that the 64 
> bit builds does not seem to honor the NO_DOCS=true flag. 
> 
> make[3]: *** No rule to make target 
> `/Users/mfranz/developer/openjdk-bsd/repos/2009-01-02/build/bsd-i586/hotspot/import/docs/platform/jvmti/jvmti.html', 
> needed by `generic_export'
> 
> Michael
> 
> 
> ------------------------------------------------------------------------
> 
> 


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/bsd-port-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/bsd-port-dev/attachments/20090103/1b9d9974/icedtea-bsd-shark.patch 
-------------- 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/bsd-port-dev/attachments/20090103/1b9d9974/icedtea-bsd-top-make.patch 

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/bsd-port-dev/attachments/20090103/aa44e3d5/attachment.html 

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 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/bsd-port-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 glewis at eyesbeyond.com  Sun Jan  4 21:06:45 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Mon, 05 Jan 2009 05:06:45 +0000
Subject: hg: bsd-port/bsd-port/hotspot: 2 new changesets
Message-ID: <20090105050652.33F93D06D@hg.openjdk.java.net>

Changeset: 7799fd334445
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-04 21:04 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/7799fd334445

. Fix casts for building on Mac OS X in 64 bit mode.

Submitted by:	Xiaobin Lu <Xiaobin.Lu at Sun.COM>

! src/cpu/x86/vm/stubGenerator_x86_64.cpp

Changeset: fbb14533a50b
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-04 21:05 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/fbb14533a50b

. Use the right bswap macro names on Mac OS X.

Submitted by:	Xiaobin Lu <Xiaobin.Lu at Sun.COM>

! src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp



From glewis at eyesbeyond.com  Sun Jan  4 21:20:39 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Sun, 4 Jan 2009 21:20:39 -0800
Subject: Patch to build 64 bit VM
In-Reply-To: <fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>
References: <494FE536.1040102@Sun.COM>
	<20081226072429.GA69479@misty.eyesbeyond.com>
	<49548922.80703@Sun.COM>
	<20081226172736.GA42840@misty.eyesbeyond.com>
	<20081228082926.GA77650@misty.eyesbeyond.com>
	<20081228205541.GA11757@misty.eyesbeyond.com>
	<4957F135.3040300@Sun.COM>
	<20081229164706.GA52523@misty.eyesbeyond.com>
	<495C475A.1030405@Sun.COM>
	<fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>
Message-ID: <20090105052039.GA21216@misty.eyesbeyond.com>

G'day Michael,

On Fri, Jan 02, 2009 at 10:59:37PM -0500, Michael Franz wrote:
> On Wed, Dec 31, 2008 at 11:32 PM, Xiaobin Lu <Xiaobin.Lu at sun.com> wrote:
> 
> > Greg,
> >
> > I tried to pass in LP64=1 to build 64 bit VM on Mac OS. This is same as
> > other platforms. It looks like you have checked in the fix to
> > os_bsd_x86.cpp so I don't believe I have to do anything more.
> >
> > Regards,
> >
> > Happy new year.
> > -Xiaobin
> >
> 
> I am not sure where this leaves the 64 bit and 32 bit builds, but I cannot
> build either without patching them.  I also noticed that the 64 bit builds
> does not seem to honor the NO_DOCS=true flag.
> 
> make[3]: *** No rule to make target
> `/Users/mfranz/developer/openjdk-bsd/repos/2009-01-02/build/bsd-i586/hotspot/import/docs/platform/jvmti/jvmti.html',
> needed by `generic_export'

I just committed the other two of Xiaobin's changes.  These help me with
the 64 bit build.  I have two patches left.  I don't think one of these
has any effect on 64 bit builds.  The other patch is to adlc.make, but I
wonder if thats just because of how I'm trying to get things to work for
64 bit builds.

I invoke GNU make with

gmake ARCH=amd64 LP64=1

(I think the LP64=1 is actually redundant).

This mostly works except it then looks for x86_64.ad in the wrong place
(src/cpu/amd64/vm instead of src/cpu/x86/vm).  I can hack around that in
adlc.make, but I have to wonder if other people are building 64 bit
differently to avoid this?

Anyway, I can get through the 64 bit HotSpot build, but my build dies
during the jdk part of the build since my userland is all 32 bit.
How are you dealing with that?

I'm still blocked by the assembler issues on 32 bit.  I think its to do
with my version of as, but I'd really like some more insight there.  Can
you please run 'as -v' and tell me the output?

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


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 mvfranz at gmail.com  Mon Jan  5 04:42:39 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Mon, 5 Jan 2009 07:42:39 -0500
Subject: Patch to build 64 bit VM
In-Reply-To: <20090105052039.GA21216@misty.eyesbeyond.com>
References: <494FE536.1040102@Sun.COM> <49548922.80703@Sun.COM>
	<20081226172736.GA42840@misty.eyesbeyond.com>
	<20081228082926.GA77650@misty.eyesbeyond.com>
	<20081228205541.GA11757@misty.eyesbeyond.com>
	<4957F135.3040300@Sun.COM>
	<20081229164706.GA52523@misty.eyesbeyond.com>
	<495C475A.1030405@Sun.COM>
	<fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>
	<20090105052039.GA21216@misty.eyesbeyond.com>
Message-ID: <fee4d890901050442n13822b7ck4e03d16642f8aaf7@mail.gmail.com>

Greg,

This is my output:
Apple Inc version cctools-698.1~1, GNU assembler version 1.38

I have been trying to build 64 bit by only passing in the LP64=1 .  I have
not been able to get it to work, it gets pretty far.  I have to change some
cast from int64_t to intprt_t to get as far as I do.

Once I put in the correct casts (change int32_t to intptr_t) the 32 bit
build is fine.

I have not imported your latest commits.

Michael

On Mon, Jan 5, 2009 at 12:20 AM, Greg Lewis <glewis at eyesbeyond.com> wrote:

> G'day Michael,
>
> On Fri, Jan 02, 2009 at 10:59:37PM -0500, Michael Franz wrote:
> > On Wed, Dec 31, 2008 at 11:32 PM, Xiaobin Lu <Xiaobin.Lu at sun.com> wrote:
> >
> > > Greg,
> > >
> > > I tried to pass in LP64=1 to build 64 bit VM on Mac OS. This is same as
> > > other platforms. It looks like you have checked in the fix to
> > > os_bsd_x86.cpp so I don't believe I have to do anything more.
> > >
> > > Regards,
> > >
> > > Happy new year.
> > > -Xiaobin
> > >
> >
> > I am not sure where this leaves the 64 bit and 32 bit builds, but I
> cannot
> > build either without patching them.  I also noticed that the 64 bit
> builds
> > does not seem to honor the NO_DOCS=true flag.
> >
> > make[3]: *** No rule to make target
> >
> `/Users/mfranz/developer/openjdk-bsd/repos/2009-01-02/build/bsd-i586/hotspot/import/docs/platform/jvmti/jvmti.html',
> > needed by `generic_export'
>
> I just committed the other two of Xiaobin's changes.  These help me with
> the 64 bit build.  I have two patches left.  I don't think one of these
> has any effect on 64 bit builds.  The other patch is to adlc.make, but I
> wonder if thats just because of how I'm trying to get things to work for
> 64 bit builds.
>
> I invoke GNU make with
>
> gmake ARCH=amd64 LP64=1
>
> (I think the LP64=1 is actually redundant).
>
> This mostly works except it then looks for x86_64.ad in the wrong place
> (src/cpu/amd64/vm instead of src/cpu/x86/vm).  I can hack around that in
> adlc.make, but I have to wonder if other people are building 64 bit
> differently to avoid this?
>
> Anyway, I can get through the 64 bit HotSpot build, but my build dies
> during the jdk part of the build since my userland is all 32 bit.
> How are you dealing with that?
>
> I'm still blocked by the assembler issues on 32 bit.  I think its to do
> with my version of as, but I'd really like some more insight there.  Can
> you please run 'as -v' and tell me the output?
>
> --
> Greg Lewis                          Email   : glewis at eyesbeyond.com
> Eyes Beyond                         Web     : http://www.eyesbeyond.com
> Information Technology              FreeBSD : glewis at FreeBSD.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090105/4c9d0aaa/attachment.html 

From gbenson at redhat.com  Mon Jan  5 07:24:22 2009
From: gbenson at redhat.com (Gary Benson)
Date: Mon, 5 Jan 2009 15:24:22 +0000
Subject: Power PC Build
In-Reply-To: <fee4d890812281106n21dacb0fh1dae3714c7ff41fb@mail.gmail.com>
References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com>
	<20081228182936.GA7488@misty.eyesbeyond.com>
	<fee4d890812281106n21dacb0fh1dae3714c7ff41fb@mail.gmail.com>
Message-ID: <20090105152421.GC3233@redhat.com>

Hi all,

Michael Franz wrote:
> On Sun, Dec 28, 2008 at 1:29 PM, Greg Lewis <glewis at eyesbeyond.com> wrote:
> > On Sat, Dec 27, 2008 at 11:12:33PM -0800, Eric Richardson wrote:
> > > I was looking into OpenJDK and saw the bsd-port and zero
> > > assembly project and thought It might be possible build jdk6 on
> > > PowerPC.  After looking at the bsd-port list I started working
> > > on setting up my environment. I have a G5 based Mac. Here is
> > > what I have done so far.
> >
> > Depending on what you want in terms of a JDK, it might be easier
> > to try and port the zero assembler work to the current OpenJDK BSD
> > port.  I'd like to do this, but I've not seen zero assembler
> > separated out from the Iced Tea sources.  I believe you need
> > libffi working to get it to work, but there are ports for this in
> > MacPorts and in at least the FreeBSD ports system (I expect it to
> > be in {Net,Open}BSD as well).
> >
> > CC'ing Gary Benson, the zero assembler author.  Gary, would it be
> > possible to get the zero assembler support as a patch against the
> > current OpenJDK 7 sources or could you point out the relevant
> > parts of the Iced Tea source?
> 
> There is a zero forest here http://hg.openjdk.java.net/ .  Is this
> the official source?  Or is it mostly maintained within the IcedTea
> project?

There's nothing in that particular forest at the moment.  The plan is
for Zero to be developed there eventually, but right now you can't
build Zero without IcedTea, so Zero development happens in the
IcedTea6 repo, http://icedtea.classpath.org/hg/icedtea6.  That's
not much use to you guys, but as Andrew Hughes said, IcedTea6 is
periodically merged into the IcedTea7 repository, 
http://icedtea.classpath.org/hg/icedtea, which can be built from
the BSD forest by using ./configure --with-project=bsd.
That would be your best bet.

Cheers,
Gary

-- 
http://gbenson.net/


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 Xiaobin.Lu at Sun.COM  Mon Jan  5 11:14:50 2009
From: Xiaobin.Lu at Sun.COM (Xiaobin Lu)
Date: Mon, 05 Jan 2009 11:14:50 -0800
Subject: Patch to build 64 bit VM
In-Reply-To: <fee4d890901050442n13822b7ck4e03d16642f8aaf7@mail.gmail.com>
References: <494FE536.1040102@Sun.COM> <49548922.80703@Sun.COM>
	<20081226172736.GA42840@misty.eyesbeyond.com>
	<20081228082926.GA77650@misty.eyesbeyond.com>
	<20081228205541.GA11757@misty.eyesbeyond.com>
	<4957F135.3040300@Sun.COM>
	<20081229164706.GA52523@misty.eyesbeyond.com>
	<495C475A.1030405@Sun.COM>
	<fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>
	<20090105052039.GA21216@misty.eyesbeyond.com>
	<fee4d890901050442n13822b7ck4e03d16642f8aaf7@mail.gmail.com>
Message-ID: <49625C2A.5080902@Sun.COM>

On 01/05/09 04:42, Michael Franz wrote:
> Greg,
>
> This is my output:
> Apple Inc version cctools-698.1~1, GNU assembler version 1.38
>
> I have been trying to build 64 bit by only passing in the LP64=1 .  I 
> have not been able to get it to work, it gets pretty far.  I have to 
> change some cast from int64_t to intprt_t to get as far as I do.
This is what I did on my Leopard system. Go to the bsd-port directory 
and type "make ALT_BOOTDIR=/usr/local/soylatte-amd64-1.0.3 LP64=1 
hotspot" and I can build the hotspot successfully. I also tried to go to 
make directory under hotspot subdirectory and type "make 
ALT_BOOTDIR=/usr/local/soylatte-amd64-1.0.3 
ALT_OUTPUTDIR=/export/bsd-port/build/bsd-port/hotspot/outputdir LP64=1 
jvmg product fastdebug" and that will do the same thing.
>
> Once I put in the correct casts (change int32_t to intptr_t) the 32 
> bit build is fine.
As I mentioned in another email, my fix for this has only been checked 
into hotspot-rt repository and hasn't been integrated to the hotspot 
repository. I assume that will happen by the end of this week or early 
next week.

-Xiaobin
>
> I have not imported your latest commits.
>
> Michael
>
> On Mon, Jan 5, 2009 at 12:20 AM, Greg Lewis <glewis at eyesbeyond.com 
> <mailto:glewis at eyesbeyond.com>> wrote:
>
>     G'day Michael,
>
>     On Fri, Jan 02, 2009 at 10:59:37PM -0500, Michael Franz wrote:
>     > On Wed, Dec 31, 2008 at 11:32 PM, Xiaobin Lu <Xiaobin.Lu at sun.com
>     <mailto:Xiaobin.Lu at sun.com>> wrote:
>     >
>     > > Greg,
>     > >
>     > > I tried to pass in LP64=1 to build 64 bit VM on Mac OS. This
>     is same as
>     > > other platforms. It looks like you have checked in the fix to
>     > > os_bsd_x86.cpp so I don't believe I have to do anything more.
>     > >
>     > > Regards,
>     > >
>     > > Happy new year.
>     > > -Xiaobin
>     > >
>     >
>     > I am not sure where this leaves the 64 bit and 32 bit builds,
>     but I cannot
>     > build either without patching them.  I also noticed that the 64
>     bit builds
>     > does not seem to honor the NO_DOCS=true flag.
>     >
>     > make[3]: *** No rule to make target
>     >
>     `/Users/mfranz/developer/openjdk-bsd/repos/2009-01-02/build/bsd-i586/hotspot/import/docs/platform/jvmti/jvmti.html',
>     > needed by `generic_export'
>
>     I just committed the other two of Xiaobin's changes.  These help
>     me with
>     the 64 bit build.  I have two patches left.  I don't think one of
>     these
>     has any effect on 64 bit builds.  The other patch is to adlc.make,
>     but I
>     wonder if thats just because of how I'm trying to get things to
>     work for
>     64 bit builds.
>
>     I invoke GNU make with
>
>     gmake ARCH=amd64 LP64=1
>
>     (I think the LP64=1 is actually redundant).
>
>     This mostly works except it then looks for x86_64.ad
>     <http://x86_64.ad> in the wrong place
>     (src/cpu/amd64/vm instead of src/cpu/x86/vm).  I can hack around
>     that in
>     adlc.make, but I have to wonder if other people are building 64 bit
>     differently to avoid this?
>
>     Anyway, I can get through the 64 bit HotSpot build, but my build dies
>     during the jdk part of the build since my userland is all 32 bit.
>     How are you dealing with that?
>
>     I'm still blocked by the assembler issues on 32 bit.  I think its
>     to do
>     with my version of as, but I'd really like some more insight
>     there.  Can
>     you please run 'as -v' and tell me the output?
>
>     --
>     Greg Lewis                          Email   :
>     glewis at eyesbeyond.com <mailto:glewis at eyesbeyond.com>
>     Eyes Beyond                         Web     :
>     http://www.eyesbeyond.com
>     Information Technology              FreeBSD : glewis at FreeBSD.org
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090105/7e627a2e/attachment.html 

From mvfranz at gmail.com  Mon Jan  5 16:44:20 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Mon, 5 Jan 2009 19:44:20 -0500
Subject: Patch to build 64 bit VM
In-Reply-To: <49625C2A.5080902@Sun.COM>
References: <494FE536.1040102@Sun.COM>
	<20081228082926.GA77650@misty.eyesbeyond.com>
	<20081228205541.GA11757@misty.eyesbeyond.com>
	<4957F135.3040300@Sun.COM>
	<20081229164706.GA52523@misty.eyesbeyond.com>
	<495C475A.1030405@Sun.COM>
	<fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>
	<20090105052039.GA21216@misty.eyesbeyond.com>
	<fee4d890901050442n13822b7ck4e03d16642f8aaf7@mail.gmail.com>
	<49625C2A.5080902@Sun.COM>
Message-ID: <fee4d890901051644s72d091d6gd59bb56fc1ed6b00@mail.gmail.com>

On Mon, Jan 5, 2009 at 2:14 PM, Xiaobin Lu <Xiaobin.Lu at sun.com> wrote:

>  On 01/05/09 04:42, Michael Franz wrote:
>
> Greg,
>
> This is my output:
> Apple Inc version cctools-698.1~1, GNU assembler version 1.38
>
> I have been trying to build 64 bit by only passing in the LP64=1 .  I have
> not been able to get it to work, it gets pretty far.  I have to change some
> cast from int64_t to intprt_t to get as far as I do.
>
> This is what I did on my Leopard system. Go to the bsd-port directory and
> type "make ALT_BOOTDIR=/usr/local/soylatte-amd64-1.0.3 LP64=1 hotspot" and I
> can build the hotspot successfully. I also tried to go to make directory
> under hotspot subdirectory and type "make
> ALT_BOOTDIR=/usr/local/soylatte-amd64-1.0.3
> ALT_OUTPUTDIR=/export/bsd-port/build/bsd-port/hotspot/outputdir LP64=1 jvmg
> product fastdebug" and that will do the same thing.
>
>
> Once I put in the correct casts (change int32_t to intptr_t) the 32 bit
> build is fine.
>
> As I mentioned in another email, my fix for this has only been checked into
> hotspot-rt repository and hasn't been integrated to the hotspot repository.
> I assume that will happen by the end of this week or early next week.
>
> -Xiaobin
>

I tried the hotspot build for LP64 and get the same error as before:
/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/bin/java
-classpath bsd_amd64_docs jvmtiGen -IN
/Users/mfranz/developer/openjdk-bsd/repos/2009-01-02/hotspot/src/share/vm/prims/jvmti.xml
-XSL
/Users/mfranz/developer/openjdk-bsd/repos/2009-01-02/hotspot/src/share/vm/prims/jvmti.xsl
-OUT bsd_amd64_docs/jvmti.html
make VM_SUBDIR=product                            generic_export
make[2]: *** No rule to make target
`/Users/mfranz/developer/openjdk-bsd/repos/2009-01-02/build/bsd-i586/hotspot/import/docs/platform/jvmti/jvmti.html',
needed by `generic_export'.  Stop.
make[1]: *** [export_product] Error 2
make: *** [hotspot-build] Error 2

I am not using Soylatte, but the openjdk binary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090105/e4118843/attachment.html 

From glewis at eyesbeyond.com  Mon Jan  5 22:12:57 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Mon, 5 Jan 2009 22:12:57 -0800
Subject: Patch to build 64 bit VM
In-Reply-To: <fee4d890901050442n13822b7ck4e03d16642f8aaf7@mail.gmail.com>
References: <49548922.80703@Sun.COM>
	<20081226172736.GA42840@misty.eyesbeyond.com>
	<20081228082926.GA77650@misty.eyesbeyond.com>
	<20081228205541.GA11757@misty.eyesbeyond.com>
	<4957F135.3040300@Sun.COM>
	<20081229164706.GA52523@misty.eyesbeyond.com>
	<495C475A.1030405@Sun.COM>
	<fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>
	<20090105052039.GA21216@misty.eyesbeyond.com>
	<fee4d890901050442n13822b7ck4e03d16642f8aaf7@mail.gmail.com>
Message-ID: <20090106061257.GA43001@misty.eyesbeyond.com>

On Mon, Jan 05, 2009 at 07:42:39AM -0500, Michael Franz wrote:
> This is my output:
> Apple Inc version cctools-698.1~1, GNU assembler version 1.38

Thank you!  A winner it looks like.  Mine is cctools-677*mumble* or
something similar.  Hmmm, now how to upgrade that...

> I have been trying to build 64 bit by only passing in the LP64=1 .  I have
> not been able to get it to work, it gets pretty far.  I have to change some
> cast from int64_t to intprt_t to get as far as I do.

Interesting.  I'll try just doing that and see what I get.

> Once I put in the correct casts (change int32_t to intptr_t) the 32 bit
> build is fine.
> 
> I have not imported your latest commits.

They were definitely necessary for me.

> On Mon, Jan 5, 2009 at 12:20 AM, Greg Lewis <glewis at eyesbeyond.com> wrote:
> 
> > G'day Michael,
> >
> > On Fri, Jan 02, 2009 at 10:59:37PM -0500, Michael Franz wrote:
> > > On Wed, Dec 31, 2008 at 11:32 PM, Xiaobin Lu <Xiaobin.Lu at sun.com> wrote:
> > >
> > > > Greg,
> > > >
> > > > I tried to pass in LP64=1 to build 64 bit VM on Mac OS. This is same as
> > > > other platforms. It looks like you have checked in the fix to
> > > > os_bsd_x86.cpp so I don't believe I have to do anything more.
> > > >
> > > > Regards,
> > > >
> > > > Happy new year.
> > > > -Xiaobin
> > > >
> > >
> > > I am not sure where this leaves the 64 bit and 32 bit builds, but I
> > cannot
> > > build either without patching them.  I also noticed that the 64 bit
> > builds
> > > does not seem to honor the NO_DOCS=true flag.
> > >
> > > make[3]: *** No rule to make target
> > >
> > `/Users/mfranz/developer/openjdk-bsd/repos/2009-01-02/build/bsd-i586/hotspot/import/docs/platform/jvmti/jvmti.html',
> > > needed by `generic_export'
> >
> > I just committed the other two of Xiaobin's changes.  These help me with
> > the 64 bit build.  I have two patches left.  I don't think one of these
> > has any effect on 64 bit builds.  The other patch is to adlc.make, but I
> > wonder if thats just because of how I'm trying to get things to work for
> > 64 bit builds.
> >
> > I invoke GNU make with
> >
> > gmake ARCH=amd64 LP64=1
> >
> > (I think the LP64=1 is actually redundant).
> >
> > This mostly works except it then looks for x86_64.ad in the wrong place
> > (src/cpu/amd64/vm instead of src/cpu/x86/vm).  I can hack around that in
> > adlc.make, but I have to wonder if other people are building 64 bit
> > differently to avoid this?
> >
> > Anyway, I can get through the 64 bit HotSpot build, but my build dies
> > during the jdk part of the build since my userland is all 32 bit.
> > How are you dealing with that?
> >
> > I'm still blocked by the assembler issues on 32 bit.  I think its to do
> > with my version of as, but I'd really like some more insight there.  Can
> > you please run 'as -v' and tell me the output?
> >
> > --
> > Greg Lewis                          Email   : glewis at eyesbeyond.com
> > Eyes Beyond                         Web     : http://www.eyesbeyond.com
> > Information Technology              FreeBSD : glewis at FreeBSD.org
> >

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From Dalibor.Topic at Sun.COM  Tue Jan  6 04:45:33 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Tue, 06 Jan 2009 13:45:33 +0100
Subject: Patch to build 64 bit VM
In-Reply-To: <20090106061257.GA43001@misty.eyesbeyond.com>
References: <49548922.80703@Sun.COM>
	<20081226172736.GA42840@misty.eyesbeyond.com>
	<20081228082926.GA77650@misty.eyesbeyond.com>
	<20081228205541.GA11757@misty.eyesbeyond.com>
	<4957F135.3040300@Sun.COM>
	<20081229164706.GA52523@misty.eyesbeyond.com>
	<495C475A.1030405@Sun.COM>
	<fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>
	<20090105052039.GA21216@misty.eyesbeyond.com>
	<fee4d890901050442n13822b7ck4e03d16642f8aaf7@mail.gmail.com>
	<20090106061257.GA43001@misty.eyesbeyond.com>
Message-ID: <4963526D.6010705@sun.com>

Greg Lewis wrote:
> On Mon, Jan 05, 2009 at 07:42:39AM -0500, Michael Franz wrote:
>   
>> This is my output:
>> Apple Inc version cctools-698.1~1, GNU assembler version 1.38
>>     
>
> Thank you!  A winner it looks like.  Mine is cctools-677*mumble* or
> something similar.  Hmmm, now how to upgrade that...
>   
It's been a while since I last played with Darwin, but cctools should be
part of the XCode download, so updating XCode should bring in a new
assembler along with it.

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 mvfranz at gmail.com  Tue Jan  6 07:36:42 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Tue, 6 Jan 2009 10:36:42 -0500
Subject: Patch to build 64 bit VM
In-Reply-To: <4963526D.6010705@sun.com>
References: <49548922.80703@Sun.COM>
	<20081228205541.GA11757@misty.eyesbeyond.com>
	<4957F135.3040300@Sun.COM>
	<20081229164706.GA52523@misty.eyesbeyond.com>
	<495C475A.1030405@Sun.COM>
	<fee4d890901021959r3880557bxfbe521cbb1e3a4@mail.gmail.com>
	<20090105052039.GA21216@misty.eyesbeyond.com>
	<fee4d890901050442n13822b7ck4e03d16642f8aaf7@mail.gmail.com>
	<20090106061257.GA43001@misty.eyesbeyond.com>
	<4963526D.6010705@sun.com>
Message-ID: <fee4d890901060736u5242fe8crb7c354217b6238a1@mail.gmail.com>

I am using Xcode 3.1.2.



On 1/6/09, Dalibor Topic <Dalibor.Topic at sun.com> wrote:
> Greg Lewis wrote:
>> On Mon, Jan 05, 2009 at 07:42:39AM -0500, Michael Franz wrote:
>>
>>> This is my output:
>>> Apple Inc version cctools-698.1~1, GNU assembler version 1.38
>>>
>>
>> Thank you!  A winner it looks like.  Mine is cctools-677*mumble* or
>> something similar.  Hmmm, now how to upgrade that...
>>
> It's been a while since I last played with Darwin, but cctools should be
> part of the XCode download, so updating XCode should bring in a new
> assembler along with it.
>
> 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
>
>
>

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


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/bsd-port-dev/attachments/20090106/07ea934e/attachment.html 

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 kurt at intricatesoftware.com  Wed Jan  7 15:48:32 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Wed, 7 Jan 2009 18:48:32 -0500
Subject: hotspot: Fix dynamic link of libjvm
Message-ID: <200901071848.33181.kurt@intricatesoftware.com>

At least for gcc 3.3.5 dynamic linking of libjvm needs to use
g++ instead of LIBS_VM += -lstdc++ to avoid getting undefined
symbols. The following patch fixes it.

Tested on FreeBSD 7.0 and OpenBSD so far. A test report for
OS X would be great.

Thanks,
-Kurt

# HG changeset patch
# User kurtmiller
# Date 1231360510 18000
# Node ID 1fcd571bc36bb02e871ff8000670a2495631b68f
# Parent  fbb14533a50b9664fd153dc348989377dd1b38c3
[mq]: link_vm.patch

diff -r fbb14533a50b -r 1fcd571bc36b make/bsd/makefiles/vm.make
--- a/make/bsd/makefiles/vm.make	Sun Jan 04 21:05:53 2009 -0800
+++ b/make/bsd/makefiles/vm.make	Wed Jan 07 15:35:10 2009 -0500
@@ -146,14 +146,14 @@
   ifeq ($(STATIC_CXX), true)
     LFLAGS_VM              += $(STATIC_LIBGCC)
     LIBS_VM                += $(STATIC_STDCXX)
+    LINK_VM                = $(LINK_LIB.c)
   else
-    LIBS_VM                += -lstdc++
+    LINK_VM                = $(LINK_LIB.CC)
   endif
 
   LIBS_VM                  += $(LIBS)
 endif
 
-LINK_VM = $(LINK_LIB.c)
 
 # rule for building precompiled header
 $(PRECOMPILED_HEADER): $(Precompiled_Files)


From kurt at intricatesoftware.com  Wed Jan  7 16:04:38 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Wed, 7 Jan 2009 19:04:38 -0500
Subject: jdk: complete SYSTEM_ZLIB build hooks and enable
Message-ID: <200901071904.38742.kurt@intricatesoftware.com>

The SYSTEM_ZLIB build flag is not complete. The following
diff completes the build hooks and enables it for OpenBSD
and FreeBSD. Tested on FreeBSD and OpenBSD and should have
no effect on OS X.

# HG changeset patch
# User kurtmiller
# Date 1231360831 18000
# Node ID 54448649b27edaaf0891ebb66897508168cb05d2
# Parent  2a26505c13046d93870a31f5a881bb47703f4438
[mq]: libz.diff

diff -r 2a26505c1304 -r 54448649b27e make/common/Defs-bsd.gmk
--- a/make/common/Defs-bsd.gmk	Sun Dec 28 10:34:23 2008 -0800
+++ b/make/common/Defs-bsd.gmk	Wed Jan 07 15:40:31 2009 -0500
@@ -286,6 +286,14 @@
 # DPS (Displayable PostScript) is available on Solaris machines
 HAVE_DPS = no
 
+ifeq ($(OS_VENDOR), FreeBSD)
+  SYSTEM_ZLIB = true
+endif
+
+ifeq ($(OS_VENDOR), OpenBSD)
+  SYSTEM_ZLIB = true
+endif
+
 #
 # Japanese manpages
 #
diff -r 2a26505c1304 -r 54448649b27e make/common/Program.gmk
--- a/make/common/Program.gmk	Sun Dec 28 10:34:23 2008 -0800
+++ b/make/common/Program.gmk	Wed Jan 07 15:40:31 2009 -0500
@@ -83,6 +83,9 @@
     LDFLAGS += -Wl,--no-whole-archive
 # Work-around an dlsym(RTLD_DEFAULT) bug in at least FreeBSD & OpenBSD
     LDFLAGS += -Wl,--export-dynamic
+  endif
+  ifeq ($(SYSTEM_ZLIB),true)
+      OTHER_LDLIBS += -lz
   endif
 endif
 ifneq (,$(findstring $(PLATFORM), linux solaris))	# UNIX systems
@@ -269,7 +272,9 @@
 endif
 
 OTHER_INCLUDES += -I$(LAUNCHER_SHARE_SRC)/bin -I$(LAUNCHER_PLATFORM_SRC)/bin
+ifneq ($(SYSTEM_ZLIB),true)
 OTHER_INCLUDES += -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3
+endif
 
 # this may not be necessary...
 ifeq ($(PLATFORM), windows)
diff -r 2a26505c1304 -r 54448649b27e make/java/jli/Makefile
--- a/make/java/jli/Makefile	Sun Dec 28 10:34:23 2008 -0800
+++ b/make/java/jli/Makefile	Wed Jan 07 15:40:31 2009 -0500
@@ -44,8 +44,10 @@
 
 include $(BUILDDIR)/common/Defs.gmk
 
+ifneq ($(SYSTEM_ZLIB),true)
 ZLIB_VERSION = 1.1.3
 ZIP_SRC = $(SHARE_SRC)/native/java/util/zip/zlib-$(ZLIB_VERSION)
+endif
 LAUNCHER_SHARE_SRC = $(SHARE_SRC)/bin
 LAUNCHER_PLATFORM_SRC = $(PLATFORM_SRC)/bin
 
@@ -66,7 +68,10 @@
 	parse_manifest.c \
 	version_comp.c \
 	wildcard.c \
-	jli_util.c \
+	jli_util.c
+
+ifneq ($(SYSTEM_ZLIB),true)
+FILES_c += \
 	inflate.c \
 	infblock.c \
 	inftrees.c \
@@ -75,6 +80,7 @@
 	infutil.c \
 	zadler32.c \
 	zutil.c
+endif
 
 ifneq ($(PLATFORM), windows)
 
@@ -125,7 +131,11 @@
 
 OTHER_INCLUDES += -I$(LAUNCHER_SHARE_SRC)
 OTHER_INCLUDES += -I$(LAUNCHER_PLATFORM_SRC)
-OTHER_INCLUDES += -I$(ZIP_SRC)
+ifneq ($(SYSTEM_ZLIB),true)
+  OTHER_INCLUDES += -I$(ZIP_SRC)
+else
+  LDLIBS += -lz
+endif
 
 #
 # Library to compile.
@@ -184,4 +194,8 @@
 #
 # Add to ambient vpath so we pick up the library files
 #
-vpath %.c $(LAUNCHER_SHARE_SRC) $(ZIP_SRC) $(LAUNCHER_PLATFORM_SRC)
+vpath %.c $(LAUNCHER_SHARE_SRC) $(LAUNCHER_PLATFORM_SRC)
+ifneq ($(SYSTEM_ZLIB),true)
+  vpath %.c $(ZIP_SRC)
+endif
+
diff -r 2a26505c1304 -r 54448649b27e make/sun/splashscreen/FILES_c.gmk
--- a/make/sun/splashscreen/FILES_c.gmk	Sun Dec 28 10:34:23 2008 -0800
+++ b/make/sun/splashscreen/FILES_c.gmk	Wed Jan 07 15:40:31 2009 -0500
@@ -49,20 +49,6 @@
 	dgif_lib.c \
 	gif_err.c \
 	gifalloc.c \
-	compress.c \
-	deflate.c \
-	gzio.c \
-	infblock.c \
-	infcodes.c \
-	inffast.c \
-	inflate.c \
-	inftrees.c \
-	infutil.c \
-	trees.c \
-	uncompr.c \
-	zadler32.c \
-	zcrc32.c \
-	zutil.c \
 	jcomapi.c \
 	jdapimin.c \
 	jdapistd.c \
@@ -108,3 +94,20 @@
 	jfdctfst.c \
 	jfdctint.c
 
+ifneq ($(SYSTEM_ZLIB),true)
+  FILES_c += \
+	compress.c \
+	deflate.c \
+	gzio.c \
+	infblock.c \
+	infcodes.c \
+	inffast.c \
+	inflate.c \
+	inftrees.c \
+	infutil.c \
+	trees.c \
+	uncompr.c \
+	zadler32.c \
+	zcrc32.c \
+	zutil.c
+endif
diff -r 2a26505c1304 -r 54448649b27e make/sun/splashscreen/Makefile
--- a/make/sun/splashscreen/Makefile	Sun Dec 28 10:34:23 2008 -0800
+++ b/make/sun/splashscreen/Makefile	Wed Jan 07 15:40:31 2009 -0500
@@ -62,7 +62,11 @@
 CFLAGS += -DSPLASHSCREEN
 
 CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen
-CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3
+CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg
+ifneq ($(SYSTEM_ZLIB),true)
+  CPPFLAGS += -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3
+endif
+
 
 ifneq ($(PLATFORM), windows)
   CFLAGS += -DWITH_X11
@@ -89,7 +93,9 @@
 vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/splashscreen
 vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)
 vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/giflib
-vpath %.c   $(SHARE_SRC)/native/java/util/zip/zlib-1.1.3
+ifneq ($(SYSTEM_ZLIB),true)
+  vpath %.c   $(SHARE_SRC)/native/java/util/zip/zlib-1.1.3
+endif
 vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/libpng
 vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/image/jpeg
 vpath %.c   $(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen


From mvfranz at gmail.com  Wed Jan  7 19:23:53 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Wed, 7 Jan 2009 22:23:53 -0500
Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display
In-Reply-To: <4965700A.10307@sun.com>
References: <fee4d890812191626i22ff982dra1740b6eeb082784@mail.gmail.com>
	<494C48CE.5010001@Sun.COM> <4965700A.10307@sun.com>
Message-ID: <fee4d890901071923h6c3bda3clb85e86756ec08cf1@mail.gmail.com>

Brad,

There is a separate thread about the socket error here:
http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000229.html

Michael

On Wed, Jan 7, 2009 at 10:16 PM, Brad Wetmore <Bradford.Wetmore at sun.com>wrote:

> >> I am running NetBeans on OS X using OpenJDK 7.
>
> >> 3. The log file has many of these exceptions:
> >> java.net.SocketException: Invalid argument
> >>         at java.net.PlainSocketImpl.socketAccept(Native Method)
>
> No idea on the network question, sorry.  I only have access to our
> Unix/Windows native code, don't have access to the Apple native Socket code
> to know what they're doing or why it's dying.
>
> Accept is a somewhat complicated bit of code.
>
> brad
>
>
> Xiaobin Lu wrote:
>
>> We noticed some similar exceptions when we ran some testings here. I
>> believe the relevant code is in the java networking code. I am ccing Brad
>> here and he might have more information on how to get around this.
>>
>> -Xiaobin
>>
>>
>> On 12/19/08 16:26, Michael Franz wrote:
>>
>>> Hi,
>>>
>>> I am running NetBeans on OS X using OpenJDK 7.  This uses the X11
>>> implementation as there is no native Cocoa/Carbon Swing implementation.
>>>  There are a few quirks that I would like to mention, maybe someone can
>>> indicate what part of the code these issue are in.
>>>
>>> 1.  Menus - the cursor is sometimes 1 line item below what is highlighted
>>> 2.  Dual display - opening  new dialogs are centered between the displays
>>> (not the current display netbeans is in).
>>> 3. The log file has many of these exceptions:
>>> java.net.SocketException: Invalid argument
>>>        at java.net.PlainSocketImpl.socketAccept(Native Method)
>>>        at
>>> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:364)
>>>        at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>>>        at java.net.ServerSocket.accept(ServerSocket.java:481)
>>>        at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010)
>>>
>>>
>>> Michael
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090107/6f3ea66e/attachment.html 

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/bsd-port-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 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/bsd-port-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 Bradford.Wetmore at Sun.COM  Wed Jan  7 19:16:26 2009
From: Bradford.Wetmore at Sun.COM (Brad Wetmore)
Date: Wed, 07 Jan 2009 19:16:26 -0800
Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display
In-Reply-To: <494C48CE.5010001@Sun.COM>
References: <fee4d890812191626i22ff982dra1740b6eeb082784@mail.gmail.com>
	<494C48CE.5010001@Sun.COM>
Message-ID: <4965700A.10307@sun.com>

 >> I am running NetBeans on OS X using OpenJDK 7.

 >> 3. The log file has many of these exceptions:
 >> java.net.SocketException: Invalid argument
 >>         at java.net.PlainSocketImpl.socketAccept(Native Method)

No idea on the network question, sorry.  I only have access to our 
Unix/Windows native code, don't have access to the Apple native Socket 
code to know what they're doing or why it's dying.

Accept is a somewhat complicated bit of code.

brad


Xiaobin Lu wrote:
> We noticed some similar exceptions when we ran some testings here. I 
> believe the relevant code is in the java networking code. I am ccing 
> Brad here and he might have more information on how to get around this.
> 
> -Xiaobin
> 
> 
> On 12/19/08 16:26, Michael Franz wrote:
>> Hi,
>>
>> I am running NetBeans on OS X using OpenJDK 7.  This uses the X11 
>> implementation as there is no native Cocoa/Carbon Swing 
>> implementation.  There are a few quirks that I would like to mention, 
>> maybe someone can indicate what part of the code these issue are in.
>>
>> 1.  Menus - the cursor is sometimes 1 line item below what is highlighted
>> 2.  Dual display - opening  new dialogs are centered between the 
>> displays (not the current display netbeans is in).
>> 3. The log file has many of these exceptions:
>> java.net.SocketException: Invalid argument
>>         at java.net.PlainSocketImpl.socketAccept(Native Method)
>>         at 
>> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:364)
>>         at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>>         at java.net.ServerSocket.accept(ServerSocket.java:481)
>>         at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010)
>>
>>
>> Michael
>> ------------------------------------------------------------------------
>>
>>
>>   
> 


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/bsd-port-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/bsd-port-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/bsd-port-dev/attachments/20090108/fde31f36/attachment.html 

From kurt at intricatesoftware.com  Fri Jan  9 07:17:35 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Fri, 09 Jan 2009 15:17:35 +0000
Subject: hg: bsd-port/bsd-port/jdk: Summary: Complete SYSTEM_ZLIB build hooks
	and enable for FreeBSD and OpenBSD
Message-ID: <20090109151803.6C021D314@hg.openjdk.java.net>

Changeset: 1536df243bf6
Author:    kurt
Date:      2009-01-09 09:01 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/1536df243bf6

Summary: Complete SYSTEM_ZLIB build hooks and enable for FreeBSD and OpenBSD
Reviewed-by: glewis

! make/common/Defs-bsd.gmk
! make/common/Program.gmk
! make/java/jli/Makefile
! make/sun/splashscreen/FILES_c.gmk
! make/sun/splashscreen/Makefile



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/bsd-port-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/bsd-port-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/bsd-port-dev/attachments/20090109/4310ef51/attachment.html 

From lists at intricatesoftware.com  Fri Jan  9 11:47:39 2009
From: lists at intricatesoftware.com (Kurt Miller)
Date: Fri, 9 Jan 2009 14:47:39 -0500
Subject: jdk: Avoid PKG_PATH build var
Message-ID: <200901091447.40404.lists@intricatesoftware.com>

PKG_PATH is a commonly set env var on Free/Open/NetBSD for
pkg_add(1). Switch to LOCALBASE which avoids the conflict and
matches Free/Open/NetBSD ports building var for /usr/local.
Also move the definition up so that Defs-bsd.gmk can use
LOCALBASE correctly.

diff -r 1536df243bf6 make/common/Defs.gmk
--- a/make/common/Defs.gmk	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/common/Defs.gmk	Fri Jan 09 14:35:28 2009 -0500
@@ -172,6 +172,24 @@
   endif
 endif # OPENJDK
 
+ifneq ($(PLATFORM), windows)
+  ifdef ALT_X11_PATH
+    X11_PATH = $(ALT_X11_PATH)
+  else
+    X11_PATH = /usr/X11R6
+  endif 
+
+  ifdef ALT_LOCALBASE
+    LOCALBASE = $(ALT_LOCALBASE)
+  else
+    ifeq ($(PLATFORM), linux)
+      LOCALBASE = /usr
+    else
+      LOCALBASE = /usr/local
+    endif
+  endif
+endif
+
 #
 # Get platform definitions
 #
@@ -230,24 +248,6 @@
       FREETYPE_HEADERS_PATH = $(DEVTOOLS_FT_DIR)/include
     else
       FREETYPE_HEADERS_PATH = /usr/include
-    endif
-  endif
-endif
-
-ifneq ($(PLATFORM), windows)
-  ifdef ALT_X11_PATH
-    X11_PATH = $(ALT_X11_PATH)
-  else
-    X11_PATH = /usr/X11R6
-  endif 
-
-  ifdef ALT_PKG_PATH
-    PKG_PATH = $(ALT_PKG_PATH)
-  else
-    ifeq ($(PLATFORM), linux)
-      PKG_PATH = /usr
-    else
-      PKG_PATH = /usr/local
     endif
   endif
 endif
diff -r 1536df243bf6 make/common/shared/Defs-bsd.gmk
--- a/make/common/shared/Defs-bsd.gmk	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/common/shared/Defs-bsd.gmk	Fri Jan 09 14:35:28 2009 -0500
@@ -54,7 +54,7 @@
 endef
 
 # Location on system where jdk installs might be
-USRJDKINSTANCES_PATH = $(PKG_PATH)
+USRJDKINSTANCES_PATH = $(LOCALBASE)
 
 # UNIXCOMMAND_PATH: path to where the most common Unix commands are.
 #  NOTE: Must end with / so that it could be empty, allowing PATH usage.
@@ -121,7 +121,7 @@
 BUILD_HEADLESS = true
 LIBM=-lm
 
-_CUPS_HEADERS_PATH=$(PKG_PATH)/include
+_CUPS_HEADERS_PATH=$(LOCALBASE)/include
 
 # Import JDK images allow for partial builds, components not built are
 #    imported (or copied from) these import areas when needed.
diff -r 1536df243bf6 make/java/instrument/Makefile
--- a/make/java/instrument/Makefile	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/java/instrument/Makefile	Fri Jan 09 14:35:28 2009 -0500
@@ -112,7 +112,7 @@
     LDFLAGS += -Wl,--no-whole-archive
   endif
 
-  ICONV_PATH = $(PKG_PATH)
+  ICONV_PATH = $(LOCALBASE)
 # Use CPPFLAGS instead of OTHER_INCLUDES to force this last
   CPPFLAGS += -I$(ICONV_PATH)/include
   OTHER_LDLIBS += -L$(ICONV_PATH)/lib -liconv
diff -r 1536df243bf6 make/java/jli/Makefile
--- a/make/java/jli/Makefile	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/java/jli/Makefile	Fri Jan 09 14:35:28 2009 -0500
@@ -97,7 +97,7 @@
   LIBARCH_DEFINES += -DLIBARCH64NAME='"$(LIBARCH64)"'
 endif
 
-OTHER_CPPFLAGS += $(LIBARCH_DEFINES) -DPKG_PATH=\"$(PKG_PATH)\"
+OTHER_CPPFLAGS += $(LIBARCH_DEFINES) -DLOCALBASE=\"$(LOCALBASE)\"
 
 
 ifneq ($(PLATFORM), windows)	# UNIX systems
diff -r 1536df243bf6 make/java/npt/Makefile
--- a/make/java/npt/Makefile	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/java/npt/Makefile	Fri Jan 09 14:35:28 2009 -0500
@@ -67,7 +67,7 @@
 
 # Add location of iconv headers
 ifeq ($(PLATFORM), bsd)
-  ICONV_PATH = $(PKG_PATH)
+  ICONV_PATH = $(LOCALBASE)
   CPPFLAGS += -I$(ICONV_PATH)/include
   OTHER_LDLIBS += -L$(ICONV_PATH)/lib -liconv
 endif
diff -r 1536df243bf6 make/sun/awt/mawt.gmk
--- a/make/sun/awt/mawt.gmk	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/sun/awt/mawt.gmk	Fri Jan 09 14:35:28 2009 -0500
@@ -250,7 +250,7 @@
 endif
 
 ifneq ($(PLATFORM), windows)
-  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DPKG_PATH=\"$(PKG_PATH)\"
+  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DLOCALBASE=\"$(LOCALBASE)\"
 endif
 
 LDFLAGS += -L$(LIBDIR)/$(LIBARCH)/$(TSOBJDIR) \
diff -r 1536df243bf6 make/sun/splashscreen/Makefile
--- a/make/sun/splashscreen/Makefile	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/sun/splashscreen/Makefile	Fri Jan 09 14:35:28 2009 -0500
@@ -72,7 +72,7 @@
   CFLAGS += -DWITH_X11
   ifeq ($(PLATFORM), bsd)
     CFLAGS += -DPNG_NO_MMX_CODE
-    ICONV_PATH = $(PKG_PATH)
+    ICONV_PATH = $(LOCALBASE)
     CPPFLAGS += -I$(OPENWIN_HOME)/include \
                 -I$(OPENWIN_HOME)/include/X11/extensions \
                 -I$(ICONV_PATH)/include
diff -r 1536df243bf6 make/sun/xawt/Makefile
--- a/make/sun/xawt/Makefile	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/sun/xawt/Makefile	Fri Jan 09 14:35:28 2009 -0500
@@ -148,7 +148,7 @@
 endif
 
 ifneq ($(PLATFORM), windows)
-  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DPKG_PATH=\"$(PKG_PATH)\"
+  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DLOCALBASE=\"$(LOCALBASE)\"
 endif
 
 ifeq ($(MILESTONE), internal)
diff -r 1536df243bf6 src/solaris/bin/java_md.c
--- a/src/solaris/bin/java_md.c	Fri Jan 09 09:01:03 2009 -0500
+++ b/src/solaris/bin/java_md.c	Fri Jan 09 14:35:28 2009 -0500
@@ -97,19 +97,19 @@
  *      entries, but actual strings can be more efficient (with many compilers).
  */
 #if defined(__FreeBSD__)
-static const char *system_dir	= PKG_PATH "/openjdk7";
+static const char *system_dir	= LOCALBASE "/openjdk7";
 static const char *user_dir	= "/java";
 #elif defined(__NetBSD__)
-static const char *system_dir	= PKG_PATH "/openjdk7";
+static const char *system_dir	= LOCALBASE "/openjdk7";
 static const char *user_dir	= "/java";
 #elif defined(__OpenBSD__)
-static const char *system_dir	= PKG_PATH "/openjdk7";
+static const char *system_dir	= LOCALBASE "/openjdk7";
 static const char *user_dir	= "/java";
 #elif defined(__APPLE__)
-static const char *system_dir	= PKG_PATH "/openjdk7";
+static const char *system_dir	= LOCALBASE "/openjdk7";
 static const char *user_dir	= "/java";
 #elif defined(__linux__)
-static const char *system_dir   = PKG_PATH "/java";
+static const char *system_dir   = LOCALBASE "/java";
 static const char *user_dir     = "/java";
 #else /* Solaris */
 static const char *system_dir   = "/usr/jdk";
diff -r 1536df243bf6 src/solaris/native/sun/awt/fontpath.c
--- a/src/solaris/native/sun/awt/fontpath.c	Fri Jan 09 09:01:03 2009 -0500
+++ b/src/solaris/native/sun/awt/fontpath.c	Fri Jan 09 14:35:28 2009 -0500
@@ -134,13 +134,13 @@
     X11_PATH "/lib/X11/fonts/tt",
     X11_PATH "/lib/X11/fonts/TTF",
     X11_PATH "/lib/X11/fonts/OTF",
-    PKG_PATH "/share/fonts/TrueType",
-    PKG_PATH "/share/fonts/truetype",
-    PKG_PATH "/share/fonts/tt",
-    PKG_PATH "/share/fonts/TTF",
-    PKG_PATH "/share/fonts/OTF",
+    LOCALBASE "/share/fonts/TrueType",
+    LOCALBASE "/share/fonts/truetype",
+    LOCALBASE "/share/fonts/tt",
+    LOCALBASE "/share/fonts/TTF",
+    LOCALBASE "/share/fonts/OTF",
     X11_PATH "/lib/X11/fonts/Type1",
-    PKG_PATH "/share/fonts/Type1",
+    LOCALBASE "/share/fonts/Type1",
     NULL, /* terminates the list */
 };
 #else /* __linux */
@@ -153,14 +153,14 @@
     X11_PATH "/lib/X11/fonts/tt",
     X11_PATH "/lib/X11/fonts/TTF",
     X11_PATH "/lib/X11/fonts/OTF",       /* RH 9.0 (but empty!) */
-    PKG_PATH "/share/fonts/ja/TrueType",       /* RH 7.2+ */
-    PKG_PATH "/share/fonts/truetype",
-    PKG_PATH "/share/fonts/ko/TrueType",       /* RH 9.0 */
-    PKG_PATH "/share/fonts/zh_CN/TrueType",    /* RH 9.0 */
-    PKG_PATH "/share/fonts/zh_TW/TrueType",    /* RH 9.0 */
+    LOCALBASE "/share/fonts/ja/TrueType",       /* RH 7.2+ */
+    LOCALBASE "/share/fonts/truetype",
+    LOCALBASE "/share/fonts/ko/TrueType",       /* RH 9.0 */
+    LOCALBASE "/share/fonts/zh_CN/TrueType",    /* RH 9.0 */
+    LOCALBASE "/share/fonts/zh_TW/TrueType",    /* RH 9.0 */
     "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType", /* Debian */
     X11_PATH "/lib/X11/fonts/Type1",
-    PKG_PATH "/share/fonts/default/Type1",     /* RH 9.0 */
+    LOCALBASE "/share/fonts/default/Type1",     /* RH 9.0 */
     NULL, /* terminates the list */
 };
 #endif


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/bsd-port-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/bsd-port-dev/attachments/20090109/75ba08c9/attachment.html 

From glewis at eyesbeyond.com  Fri Jan  9 20:26:56 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Fri, 9 Jan 2009 20:26:56 -0800
Subject: jdk: Avoid PKG_PATH build var
In-Reply-To: <200901091447.40404.lists@intricatesoftware.com>
References: <200901091447.40404.lists@intricatesoftware.com>
Message-ID: <20090110042656.GA86176@misty.eyesbeyond.com>

G'day Kurt,

On Fri, Jan 09, 2009 at 02:47:39PM -0500, Kurt Miller wrote:
> PKG_PATH is a commonly set env var on Free/Open/NetBSD for
> pkg_add(1). Switch to LOCALBASE which avoids the conflict and
> matches Free/Open/NetBSD ports building var for /usr/local.
> Also move the definition up so that Defs-bsd.gmk can use
> LOCALBASE correctly.

I really wanted to avoid LOCALBASE when I implemented that because
all the other "path" environment variables that the build uses end in
_PATH (well, except for ALT_BOOTDIR I guess).  It also seemed biased
towards {Free,Net,Open}BSD over Mac OS X.  Thats also why it ended
up being X11_PATH rather than X11BASE.

PKG_PATH seemed a good fit -- I didn't realise that pkg_add used it
(probably because I pretty much always build from ports rather than
installing packages :).  It also worked for Linux and Solaris (most
of the changes aren't BSD specific files) since they both have a
concept of installing third party software packages somewhere.

LOCALBASE (and LOCAL_PATH for that matter) aren't really going to
be intuitive to most Linux and Solaris users, IMO.

How about PACKAGE_PATH?  Thats unfortunately much longer, and I'm
sure it still collides with some utility somewhere, but at least it
doesn't collide with an obvious one for us :).

> diff -r 1536df243bf6 make/common/Defs.gmk
> --- a/make/common/Defs.gmk	Fri Jan 09 09:01:03 2009 -0500
> +++ b/make/common/Defs.gmk	Fri Jan 09 14:35:28 2009 -0500
> @@ -172,6 +172,24 @@
>    endif
>  endif # OPENJDK
>  
> +ifneq ($(PLATFORM), windows)
> +  ifdef ALT_X11_PATH
> +    X11_PATH = $(ALT_X11_PATH)
> +  else
> +    X11_PATH = /usr/X11R6
> +  endif 
> +
> +  ifdef ALT_LOCALBASE
> +    LOCALBASE = $(ALT_LOCALBASE)
> +  else
> +    ifeq ($(PLATFORM), linux)
> +      LOCALBASE = /usr
> +    else
> +      LOCALBASE = /usr/local
> +    endif
> +  endif
> +endif
> +
>  #
>  # Get platform definitions
>  #
> @@ -230,24 +248,6 @@
>        FREETYPE_HEADERS_PATH = $(DEVTOOLS_FT_DIR)/include
>      else
>        FREETYPE_HEADERS_PATH = /usr/include
> -    endif
> -  endif
> -endif
> -
> -ifneq ($(PLATFORM), windows)
> -  ifdef ALT_X11_PATH
> -    X11_PATH = $(ALT_X11_PATH)
> -  else
> -    X11_PATH = /usr/X11R6
> -  endif 
> -
> -  ifdef ALT_PKG_PATH
> -    PKG_PATH = $(ALT_PKG_PATH)
> -  else
> -    ifeq ($(PLATFORM), linux)
> -      PKG_PATH = /usr
> -    else
> -      PKG_PATH = /usr/local
>      endif
>    endif
>  endif
> diff -r 1536df243bf6 make/common/shared/Defs-bsd.gmk
> --- a/make/common/shared/Defs-bsd.gmk	Fri Jan 09 09:01:03 2009 -0500
> +++ b/make/common/shared/Defs-bsd.gmk	Fri Jan 09 14:35:28 2009 -0500
> @@ -54,7 +54,7 @@
>  endef
>  
>  # Location on system where jdk installs might be
> -USRJDKINSTANCES_PATH = $(PKG_PATH)
> +USRJDKINSTANCES_PATH = $(LOCALBASE)
>  
>  # UNIXCOMMAND_PATH: path to where the most common Unix commands are.
>  #  NOTE: Must end with / so that it could be empty, allowing PATH usage.
> @@ -121,7 +121,7 @@
>  BUILD_HEADLESS = true
>  LIBM=-lm
>  
> -_CUPS_HEADERS_PATH=$(PKG_PATH)/include
> +_CUPS_HEADERS_PATH=$(LOCALBASE)/include
>  
>  # Import JDK images allow for partial builds, components not built are
>  #    imported (or copied from) these import areas when needed.
> diff -r 1536df243bf6 make/java/instrument/Makefile
> --- a/make/java/instrument/Makefile	Fri Jan 09 09:01:03 2009 -0500
> +++ b/make/java/instrument/Makefile	Fri Jan 09 14:35:28 2009 -0500
> @@ -112,7 +112,7 @@
>      LDFLAGS += -Wl,--no-whole-archive
>    endif
>  
> -  ICONV_PATH = $(PKG_PATH)
> +  ICONV_PATH = $(LOCALBASE)
>  # Use CPPFLAGS instead of OTHER_INCLUDES to force this last
>    CPPFLAGS += -I$(ICONV_PATH)/include
>    OTHER_LDLIBS += -L$(ICONV_PATH)/lib -liconv
> diff -r 1536df243bf6 make/java/jli/Makefile
> --- a/make/java/jli/Makefile	Fri Jan 09 09:01:03 2009 -0500
> +++ b/make/java/jli/Makefile	Fri Jan 09 14:35:28 2009 -0500
> @@ -97,7 +97,7 @@
>    LIBARCH_DEFINES += -DLIBARCH64NAME='"$(LIBARCH64)"'
>  endif
>  
> -OTHER_CPPFLAGS += $(LIBARCH_DEFINES) -DPKG_PATH=\"$(PKG_PATH)\"
> +OTHER_CPPFLAGS += $(LIBARCH_DEFINES) -DLOCALBASE=\"$(LOCALBASE)\"
>  
>  
>  ifneq ($(PLATFORM), windows)	# UNIX systems
> diff -r 1536df243bf6 make/java/npt/Makefile
> --- a/make/java/npt/Makefile	Fri Jan 09 09:01:03 2009 -0500
> +++ b/make/java/npt/Makefile	Fri Jan 09 14:35:28 2009 -0500
> @@ -67,7 +67,7 @@
>  
>  # Add location of iconv headers
>  ifeq ($(PLATFORM), bsd)
> -  ICONV_PATH = $(PKG_PATH)
> +  ICONV_PATH = $(LOCALBASE)
>    CPPFLAGS += -I$(ICONV_PATH)/include
>    OTHER_LDLIBS += -L$(ICONV_PATH)/lib -liconv
>  endif
> diff -r 1536df243bf6 make/sun/awt/mawt.gmk
> --- a/make/sun/awt/mawt.gmk	Fri Jan 09 09:01:03 2009 -0500
> +++ b/make/sun/awt/mawt.gmk	Fri Jan 09 14:35:28 2009 -0500
> @@ -250,7 +250,7 @@
>  endif
>  
>  ifneq ($(PLATFORM), windows)
> -  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DPKG_PATH=\"$(PKG_PATH)\"
> +  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DLOCALBASE=\"$(LOCALBASE)\"
>  endif
>  
>  LDFLAGS += -L$(LIBDIR)/$(LIBARCH)/$(TSOBJDIR) \
> diff -r 1536df243bf6 make/sun/splashscreen/Makefile
> --- a/make/sun/splashscreen/Makefile	Fri Jan 09 09:01:03 2009 -0500
> +++ b/make/sun/splashscreen/Makefile	Fri Jan 09 14:35:28 2009 -0500
> @@ -72,7 +72,7 @@
>    CFLAGS += -DWITH_X11
>    ifeq ($(PLATFORM), bsd)
>      CFLAGS += -DPNG_NO_MMX_CODE
> -    ICONV_PATH = $(PKG_PATH)
> +    ICONV_PATH = $(LOCALBASE)
>      CPPFLAGS += -I$(OPENWIN_HOME)/include \
>                  -I$(OPENWIN_HOME)/include/X11/extensions \
>                  -I$(ICONV_PATH)/include
> diff -r 1536df243bf6 make/sun/xawt/Makefile
> --- a/make/sun/xawt/Makefile	Fri Jan 09 09:01:03 2009 -0500
> +++ b/make/sun/xawt/Makefile	Fri Jan 09 14:35:28 2009 -0500
> @@ -148,7 +148,7 @@
>  endif
>  
>  ifneq ($(PLATFORM), windows)
> -  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DPKG_PATH=\"$(PKG_PATH)\"
> +  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DLOCALBASE=\"$(LOCALBASE)\"
>  endif
>  
>  ifeq ($(MILESTONE), internal)
> diff -r 1536df243bf6 src/solaris/bin/java_md.c
> --- a/src/solaris/bin/java_md.c	Fri Jan 09 09:01:03 2009 -0500
> +++ b/src/solaris/bin/java_md.c	Fri Jan 09 14:35:28 2009 -0500
> @@ -97,19 +97,19 @@
>   *      entries, but actual strings can be more efficient (with many compilers).
>   */
>  #if defined(__FreeBSD__)
> -static const char *system_dir	= PKG_PATH "/openjdk7";
> +static const char *system_dir	= LOCALBASE "/openjdk7";
>  static const char *user_dir	= "/java";
>  #elif defined(__NetBSD__)
> -static const char *system_dir	= PKG_PATH "/openjdk7";
> +static const char *system_dir	= LOCALBASE "/openjdk7";
>  static const char *user_dir	= "/java";
>  #elif defined(__OpenBSD__)
> -static const char *system_dir	= PKG_PATH "/openjdk7";
> +static const char *system_dir	= LOCALBASE "/openjdk7";
>  static const char *user_dir	= "/java";
>  #elif defined(__APPLE__)
> -static const char *system_dir	= PKG_PATH "/openjdk7";
> +static const char *system_dir	= LOCALBASE "/openjdk7";
>  static const char *user_dir	= "/java";
>  #elif defined(__linux__)
> -static const char *system_dir   = PKG_PATH "/java";
> +static const char *system_dir   = LOCALBASE "/java";
>  static const char *user_dir     = "/java";
>  #else /* Solaris */
>  static const char *system_dir   = "/usr/jdk";
> diff -r 1536df243bf6 src/solaris/native/sun/awt/fontpath.c
> --- a/src/solaris/native/sun/awt/fontpath.c	Fri Jan 09 09:01:03 2009 -0500
> +++ b/src/solaris/native/sun/awt/fontpath.c	Fri Jan 09 14:35:28 2009 -0500
> @@ -134,13 +134,13 @@
>      X11_PATH "/lib/X11/fonts/tt",
>      X11_PATH "/lib/X11/fonts/TTF",
>      X11_PATH "/lib/X11/fonts/OTF",
> -    PKG_PATH "/share/fonts/TrueType",
> -    PKG_PATH "/share/fonts/truetype",
> -    PKG_PATH "/share/fonts/tt",
> -    PKG_PATH "/share/fonts/TTF",
> -    PKG_PATH "/share/fonts/OTF",
> +    LOCALBASE "/share/fonts/TrueType",
> +    LOCALBASE "/share/fonts/truetype",
> +    LOCALBASE "/share/fonts/tt",
> +    LOCALBASE "/share/fonts/TTF",
> +    LOCALBASE "/share/fonts/OTF",
>      X11_PATH "/lib/X11/fonts/Type1",
> -    PKG_PATH "/share/fonts/Type1",
> +    LOCALBASE "/share/fonts/Type1",
>      NULL, /* terminates the list */
>  };
>  #else /* __linux */
> @@ -153,14 +153,14 @@
>      X11_PATH "/lib/X11/fonts/tt",
>      X11_PATH "/lib/X11/fonts/TTF",
>      X11_PATH "/lib/X11/fonts/OTF",       /* RH 9.0 (but empty!) */
> -    PKG_PATH "/share/fonts/ja/TrueType",       /* RH 7.2+ */
> -    PKG_PATH "/share/fonts/truetype",
> -    PKG_PATH "/share/fonts/ko/TrueType",       /* RH 9.0 */
> -    PKG_PATH "/share/fonts/zh_CN/TrueType",    /* RH 9.0 */
> -    PKG_PATH "/share/fonts/zh_TW/TrueType",    /* RH 9.0 */
> +    LOCALBASE "/share/fonts/ja/TrueType",       /* RH 7.2+ */
> +    LOCALBASE "/share/fonts/truetype",
> +    LOCALBASE "/share/fonts/ko/TrueType",       /* RH 9.0 */
> +    LOCALBASE "/share/fonts/zh_CN/TrueType",    /* RH 9.0 */
> +    LOCALBASE "/share/fonts/zh_TW/TrueType",    /* RH 9.0 */
>      "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType", /* Debian */
>      X11_PATH "/lib/X11/fonts/Type1",
> -    PKG_PATH "/share/fonts/default/Type1",     /* RH 9.0 */
> +    LOCALBASE "/share/fonts/default/Type1",     /* RH 9.0 */
>      NULL, /* terminates the list */
>  };
>  #endif

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


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 kurt at intricatesoftware.com  Sat Jan 10 05:07:48 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Sat, 10 Jan 2009 08:07:48 -0500
Subject: jdk: Avoid PKG_PATH build var
Message-ID: <200901100807.49229.kurt@intricatesoftware.com>

Hi Greg,

Greg Lewis wrote:
> G'day Kurt,
> 
> On Fri, Jan 09, 2009 at 02:47:39PM -0500, Kurt Miller wrote:
>> PKG_PATH is a commonly set env var on Free/Open/NetBSD for
>> pkg_add(1). Switch to LOCALBASE which avoids the conflict and
>> matches Free/Open/NetBSD ports building var for /usr/local.
>> Also move the definition up so that Defs-bsd.gmk can use
>> LOCALBASE correctly.
> 
> I really wanted to avoid LOCALBASE when I implemented that because
> all the other "path" environment variables that the build uses end in
> _PATH (well, except for ALT_BOOTDIR I guess).  It also seemed biased
> towards {Free,Net,Open}BSD over Mac OS X.  Thats also why it ended
> up being X11_PATH rather than X11BASE.

Ahh, ok.

> PKG_PATH seemed a good fit -- I didn't realise that pkg_add used it
> (probably because I pretty much always build from ports rather than
> installing packages :).  It also worked for Linux and Solaris (most
> of the changes aren't BSD specific files) since they both have a
> concept of installing third party software packages somewhere.
> 
> LOCALBASE (and LOCAL_PATH for that matter) aren't really going to
> be intuitive to most Linux and Solaris users, IMO.
> 
> How about PACKAGE_PATH?  Thats unfortunately much longer, and I'm
> sure it still collides with some utility somewhere, but at least it
> doesn't collide with an obvious one for us :).

That sounds fine with me. Google didn't find anything of concern
using that name.

The updated diff follows.

diff -r 1536df243bf6 make/common/Defs.gmk
--- a/make/common/Defs.gmk	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/common/Defs.gmk	Sat Jan 10 07:44:04 2009 -0500
@@ -172,6 +172,24 @@
   endif
 endif # OPENJDK
 
+ifneq ($(PLATFORM), windows)
+  ifdef ALT_X11_PATH
+    X11_PATH = $(ALT_X11_PATH)
+  else
+    X11_PATH = /usr/X11R6
+  endif 
+
+  ifdef ALT_PACKAGE_PATH
+    PACKAGE_PATH = $(ALT_PACKAGE_PATH)
+  else
+    ifeq ($(PLATFORM), linux)
+      PACKAGE_PATH = /usr
+    else
+      PACKAGE_PATH = /usr/local
+    endif
+  endif
+endif
+
 #
 # Get platform definitions
 #
@@ -230,24 +248,6 @@
       FREETYPE_HEADERS_PATH = $(DEVTOOLS_FT_DIR)/include
     else
       FREETYPE_HEADERS_PATH = /usr/include
-    endif
-  endif
-endif
-
-ifneq ($(PLATFORM), windows)
-  ifdef ALT_X11_PATH
-    X11_PATH = $(ALT_X11_PATH)
-  else
-    X11_PATH = /usr/X11R6
-  endif 
-
-  ifdef ALT_PKG_PATH
-    PKG_PATH = $(ALT_PKG_PATH)
-  else
-    ifeq ($(PLATFORM), linux)
-      PKG_PATH = /usr
-    else
-      PKG_PATH = /usr/local
     endif
   endif
 endif
diff -r 1536df243bf6 make/common/shared/Defs-bsd.gmk
--- a/make/common/shared/Defs-bsd.gmk	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/common/shared/Defs-bsd.gmk	Sat Jan 10 07:44:04 2009 -0500
@@ -54,7 +54,7 @@
 endef
 
 # Location on system where jdk installs might be
-USRJDKINSTANCES_PATH = $(PKG_PATH)
+USRJDKINSTANCES_PATH = $(PACKAGE_PATH)
 
 # UNIXCOMMAND_PATH: path to where the most common Unix commands are.
 #  NOTE: Must end with / so that it could be empty, allowing PATH usage.
@@ -121,7 +121,7 @@
 BUILD_HEADLESS = true
 LIBM=-lm
 
-_CUPS_HEADERS_PATH=$(PKG_PATH)/include
+_CUPS_HEADERS_PATH=$(PACKAGE_PATH)/include
 
 # Import JDK images allow for partial builds, components not built are
 #    imported (or copied from) these import areas when needed.
diff -r 1536df243bf6 make/java/instrument/Makefile
--- a/make/java/instrument/Makefile	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/java/instrument/Makefile	Sat Jan 10 07:44:04 2009 -0500
@@ -112,7 +112,7 @@
     LDFLAGS += -Wl,--no-whole-archive
   endif
 
-  ICONV_PATH = $(PKG_PATH)
+  ICONV_PATH = $(PACKAGE_PATH)
 # Use CPPFLAGS instead of OTHER_INCLUDES to force this last
   CPPFLAGS += -I$(ICONV_PATH)/include
   OTHER_LDLIBS += -L$(ICONV_PATH)/lib -liconv
diff -r 1536df243bf6 make/java/jli/Makefile
--- a/make/java/jli/Makefile	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/java/jli/Makefile	Sat Jan 10 07:44:04 2009 -0500
@@ -97,7 +97,7 @@
   LIBARCH_DEFINES += -DLIBARCH64NAME='"$(LIBARCH64)"'
 endif
 
-OTHER_CPPFLAGS += $(LIBARCH_DEFINES) -DPKG_PATH=\"$(PKG_PATH)\"
+OTHER_CPPFLAGS += $(LIBARCH_DEFINES) -DPACKAGE_PATH=\"$(PACKAGE_PATH)\"
 
 
 ifneq ($(PLATFORM), windows)	# UNIX systems
diff -r 1536df243bf6 make/java/npt/Makefile
--- a/make/java/npt/Makefile	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/java/npt/Makefile	Sat Jan 10 07:44:04 2009 -0500
@@ -67,7 +67,7 @@
 
 # Add location of iconv headers
 ifeq ($(PLATFORM), bsd)
-  ICONV_PATH = $(PKG_PATH)
+  ICONV_PATH = $(PACKAGE_PATH)
   CPPFLAGS += -I$(ICONV_PATH)/include
   OTHER_LDLIBS += -L$(ICONV_PATH)/lib -liconv
 endif
diff -r 1536df243bf6 make/sun/awt/mawt.gmk
--- a/make/sun/awt/mawt.gmk	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/sun/awt/mawt.gmk	Sat Jan 10 07:44:04 2009 -0500
@@ -250,7 +250,7 @@
 endif
 
 ifneq ($(PLATFORM), windows)
-  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DPKG_PATH=\"$(PKG_PATH)\"
+  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DPACKAGE_PATH=\"$(PACKAGE_PATH)\"
 endif
 
 LDFLAGS += -L$(LIBDIR)/$(LIBARCH)/$(TSOBJDIR) \
diff -r 1536df243bf6 make/sun/splashscreen/Makefile
--- a/make/sun/splashscreen/Makefile	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/sun/splashscreen/Makefile	Sat Jan 10 07:44:04 2009 -0500
@@ -72,7 +72,7 @@
   CFLAGS += -DWITH_X11
   ifeq ($(PLATFORM), bsd)
     CFLAGS += -DPNG_NO_MMX_CODE
-    ICONV_PATH = $(PKG_PATH)
+    ICONV_PATH = $(PACKAGE_PATH)
     CPPFLAGS += -I$(OPENWIN_HOME)/include \
                 -I$(OPENWIN_HOME)/include/X11/extensions \
                 -I$(ICONV_PATH)/include
diff -r 1536df243bf6 make/sun/xawt/Makefile
--- a/make/sun/xawt/Makefile	Fri Jan 09 09:01:03 2009 -0500
+++ b/make/sun/xawt/Makefile	Sat Jan 10 07:44:04 2009 -0500
@@ -148,7 +148,7 @@
 endif
 
 ifneq ($(PLATFORM), windows)
-  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DPKG_PATH=\"$(PKG_PATH)\"
+  CPPFLAGS += -DX11_PATH=\"$(X11_PATH)\" -DPACKAGE_PATH=\"$(PACKAGE_PATH)\"
 endif
 
 ifeq ($(MILESTONE), internal)
diff -r 1536df243bf6 src/solaris/bin/java_md.c
--- a/src/solaris/bin/java_md.c	Fri Jan 09 09:01:03 2009 -0500
+++ b/src/solaris/bin/java_md.c	Sat Jan 10 07:44:04 2009 -0500
@@ -97,19 +97,19 @@
  *      entries, but actual strings can be more efficient (with many compilers).
  */
 #if defined(__FreeBSD__)
-static const char *system_dir	= PKG_PATH "/openjdk7";
+static const char *system_dir	= PACKAGE_PATH "/openjdk7";
 static const char *user_dir	= "/java";
 #elif defined(__NetBSD__)
-static const char *system_dir	= PKG_PATH "/openjdk7";
+static const char *system_dir	= PACKAGE_PATH "/openjdk7";
 static const char *user_dir	= "/java";
 #elif defined(__OpenBSD__)
-static const char *system_dir	= PKG_PATH "/openjdk7";
+static const char *system_dir	= PACKAGE_PATH "/openjdk7";
 static const char *user_dir	= "/java";
 #elif defined(__APPLE__)
-static const char *system_dir	= PKG_PATH "/openjdk7";
+static const char *system_dir	= PACKAGE_PATH "/openjdk7";
 static const char *user_dir	= "/java";
 #elif defined(__linux__)
-static const char *system_dir   = PKG_PATH "/java";
+static const char *system_dir   = PACKAGE_PATH "/java";
 static const char *user_dir     = "/java";
 #else /* Solaris */
 static const char *system_dir   = "/usr/jdk";
diff -r 1536df243bf6 src/solaris/native/sun/awt/fontpath.c
--- a/src/solaris/native/sun/awt/fontpath.c	Fri Jan 09 09:01:03 2009 -0500
+++ b/src/solaris/native/sun/awt/fontpath.c	Sat Jan 10 07:44:04 2009 -0500
@@ -134,13 +134,13 @@
     X11_PATH "/lib/X11/fonts/tt",
     X11_PATH "/lib/X11/fonts/TTF",
     X11_PATH "/lib/X11/fonts/OTF",
-    PKG_PATH "/share/fonts/TrueType",
-    PKG_PATH "/share/fonts/truetype",
-    PKG_PATH "/share/fonts/tt",
-    PKG_PATH "/share/fonts/TTF",
-    PKG_PATH "/share/fonts/OTF",
+    PACKAGE_PATH "/share/fonts/TrueType",
+    PACKAGE_PATH "/share/fonts/truetype",
+    PACKAGE_PATH "/share/fonts/tt",
+    PACKAGE_PATH "/share/fonts/TTF",
+    PACKAGE_PATH "/share/fonts/OTF",
     X11_PATH "/lib/X11/fonts/Type1",
-    PKG_PATH "/share/fonts/Type1",
+    PACKAGE_PATH "/share/fonts/Type1",
     NULL, /* terminates the list */
 };
 #else /* __linux */
@@ -153,14 +153,14 @@
     X11_PATH "/lib/X11/fonts/tt",
     X11_PATH "/lib/X11/fonts/TTF",
     X11_PATH "/lib/X11/fonts/OTF",       /* RH 9.0 (but empty!) */
-    PKG_PATH "/share/fonts/ja/TrueType",       /* RH 7.2+ */
-    PKG_PATH "/share/fonts/truetype",
-    PKG_PATH "/share/fonts/ko/TrueType",       /* RH 9.0 */
-    PKG_PATH "/share/fonts/zh_CN/TrueType",    /* RH 9.0 */
-    PKG_PATH "/share/fonts/zh_TW/TrueType",    /* RH 9.0 */
+    PACKAGE_PATH "/share/fonts/ja/TrueType",       /* RH 7.2+ */
+    PACKAGE_PATH "/share/fonts/truetype",
+    PACKAGE_PATH "/share/fonts/ko/TrueType",       /* RH 9.0 */
+    PACKAGE_PATH "/share/fonts/zh_CN/TrueType",    /* RH 9.0 */
+    PACKAGE_PATH "/share/fonts/zh_TW/TrueType",    /* RH 9.0 */
     "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType", /* Debian */
     X11_PATH "/lib/X11/fonts/Type1",
-    PKG_PATH "/share/fonts/default/Type1",     /* RH 9.0 */
+    PACKAGE_PATH "/share/fonts/default/Type1",     /* RH 9.0 */
     NULL, /* terminates the list */
 };
 #endif


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/bsd-port-dev/attachments/20090110/92f236af/attachment.html 

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/bsd-port-dev/attachments/20090110/f7296259/attachment.html 

From kurt at intricatesoftware.com  Sat Jan 10 19:15:24 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Sun, 11 Jan 2009 03:15:24 +0000
Subject: hg: bsd-port/bsd-port/jdk: Summary: Avoid PKG_PATH build var
Message-ID: <20090111031538.0C665D381@hg.openjdk.java.net>

Changeset: 52c015181055
Author:    kurt
Date:      2009-01-10 22:13 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/52c015181055

Summary: Avoid PKG_PATH build var
Reviewed-by: glewis

! make/common/Defs.gmk
! make/common/shared/Defs-bsd.gmk
! make/java/instrument/Makefile
! make/java/jli/Makefile
! make/java/npt/Makefile
! make/sun/awt/mawt.gmk
! make/sun/splashscreen/Makefile
! make/sun/xawt/Makefile
! src/solaris/bin/java_md.c
! src/solaris/native/sun/awt/fontpath.c



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/bsd-port-dev/attachments/20090111/7756fb20/Makefile.am.escape.patch 

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 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 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/bsd-port-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/bsd-port-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/bsd-port-dev/attachments/20090111/51fdc704/attachment.html 

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/bsd-port-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/bsd-port-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 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 kurt at intricatesoftware.com  Mon Jan 12 12:47:26 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Mon, 12 Jan 2009 15:47:26 -0500
Subject: jdk: Path corrections (utils & cups)
Message-ID: <200901121547.26589.kurt@intricatesoftware.com>

The following diff cleans up paths for utils defined Def-utils.gmk
as well as setting the correct default cups headers path for Apple.

I have tested it on OpenBSD and FreeBSD but I don't have OS X on
x86 to do a test build. However, I carefully checked the paths on
my Lepoard/ppc laptop to ensure they are correct for Apple too.

- Set DEVTOOLS_PATH to $(PACKAGE_PATH)/bin/ which is the correct
  location for tools that don't come preinstalled with the platform.
- Set _CUPS_HEADERS_PATH correctly for Apple which comes
  with cups.
- Set up full paths to utils defined in Defs-utils.gmk
  for bsd with exceptions for OS_VENDOR differences.

diff -r 52c015181055 make/common/shared/Defs-bsd.gmk
--- a/make/common/shared/Defs-bsd.gmk	Sat Jan 10 22:13:03 2009 -0500
+++ b/make/common/shared/Defs-bsd.gmk	Sun Jan 11 21:30:19 2009 -0500
@@ -107,7 +107,7 @@
 ifneq "$(origin ALT_DEVTOOLS_PATH)" "undefined"
   DEVTOOLS_PATH :=$(call PrefixPath,$(ALT_DEVTOOLS_PATH))
 else
-  DEVTOOLS_PATH =/usr/bin/
+  DEVTOOLS_PATH =$(PACKAGE_PATH)/bin/
 endif
 
 # _BOOTDIR1: First choice for a Bootstrap JDK, previous released JDK.
@@ -121,7 +121,11 @@
 BUILD_HEADLESS = true
 LIBM=-lm
 
-_CUPS_HEADERS_PATH=$(PACKAGE_PATH)/include
+ifeq ($(OS_VENDOR), Apple)
+  _CUPS_HEADERS_PATH=/usr/include
+else
+  _CUPS_HEADERS_PATH=$(PACKAGE_PATH)/include
+endif
 
 # Import JDK images allow for partial builds, components not built are
 #    imported (or copied from) these import areas when needed.
diff -r 52c015181055 make/common/shared/Defs-utils.gmk
--- a/make/common/shared/Defs-utils.gmk	Sat Jan 10 22:13:03 2009 -0500
+++ b/make/common/shared/Defs-utils.gmk	Sun Jan 11 21:30:19 2009 -0500
@@ -64,6 +64,13 @@
   UTILS_COMMAND_PATH=$(UNIXCOMMAND_PATH)
   UTILS_USR_BIN_PATH=$(UNIXCOMMAND_PATH)
   UTILS_CCS_BIN_PATH=$(UNIXCOMMAND_PATH)
+  UTILS_DEVTOOL_PATH=$(DEVTOOLS_PATH)
+endif
+
+ifeq ($(PLATFORM),bsd)
+  UTILS_COMMAND_PATH=$(UNIXCOMMAND_PATH)
+  UTILS_USR_BIN_PATH=$(USRBIN_PATH)
+  UTILS_CCS_BIN_PATH=$(USRBIN_PATH)
   UTILS_DEVTOOL_PATH=$(DEVTOOLS_PATH)
 endif
 
@@ -202,6 +209,32 @@
 endif
 
 # BSD specific
-ifeq ($(SYSTEM_UNAME),Darwin)
-  NAWK = $(USRBIN_PATH)awk
+ifeq ($(PLATFORM),bsd)
+  BASENAME     = $(UTILS_USR_BIN_PATH)basename
+  EGREP        = $(UTILS_USR_BIN_PATH)egrep
+  EXPR         = $(UTILS_COMMAND_PATH)expr
+  FMT          = $(UTILS_USR_BIN_PATH)fmt
+  GREP         = $(UTILS_USR_BIN_PATH)grep
+  GUNZIP       = $(UTILS_USR_BIN_PATH)gunzip
+  ID           = $(UTILS_USR_BIN_PATH)id
+  MSGFMT       = $(UTILS_DEVTOOL_PATH)msgfmt
+  SED          = $(UTILS_USR_BIN_PATH)sed
+  SORT         = $(UTILS_USR_BIN_PATH)sort
+  TEST         = $(UTILS_COMMAND_PATH)test
+  TOUCH        = $(UTILS_USR_BIN_PATH)touch
+  TRUE         = $(UTILS_USR_BIN_PATH)true
+  UNAME        = $(UTILS_USR_BIN_PATH)uname
+  # BSD OS_VENDOR specific
+  ifeq ($(OS_VENDOR), Apple)
+    NAWK       = $(UTILS_USR_BIN_PATH)awk
+    UNZIP      = $(UTILS_USR_BIN_PATH)unzip
+    UNZIPSFX   = $(UTILS_USR_BIN_PATH)unzipsfx
+    ZIP        = $(UTILS_USR_BIN_PATH)zip
+  else
+    UNZIP      = $(UTILS_DEVTOOL_PATH)unzip
+  endif
+  ifneq ($(OS_VENDOR), OpenBSD)
+    CPIO       = $(UTILS_USR_BIN_PATH)cpio
+    TAR        = $(UTILS_USR_BIN_PATH)tar
+  endif
 endif


From kurt at intricatesoftware.com  Mon Jan 12 12:50:04 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Mon, 12 Jan 2009 15:50:04 -0500
Subject: corba: Path corrections (utils & misc others)
Message-ID: <200901121550.04514.kurt@intricatesoftware.com>

The following diff cleans up paths for utils defined Def-utils.gmk
and sets other paths to be consistant with the jdk tree's version
of them.

Tested the same as the jdk version of the diff. i.e. Test builds
on OpenBSD and FreeBSD, by inspection on Apple.

- Sync Defs.gmk with jdk version by defining PACKAGE_PATH and moving
  the X11_PATH definition to before including platform definitions.
- Set DEVTOOLS_PATH to $(PACKAGE_PATH)/bin/ which is the correct
  location for tools that don't come preinstalled with the platform.
- Sync USRJDKINSTANCES_PATH to match the corresponding jdk value.
- Set up full paths to utils defined in Defs-utils.gmk
  for bsd with exceptions for OS_VENDOR differences.

diff -r 75576a3af8a1 make/common/Defs.gmk
--- a/make/common/Defs.gmk	Fri Dec 26 08:48:04 2008 -0800
+++ b/make/common/Defs.gmk	Sun Jan 11 21:28:43 2009 -0500
@@ -53,6 +53,24 @@
 
 _OUTPUTDIR=$(TOPDIR)/build/$(PLATFORM)-$(ARCH)
 
+ifneq ($(PLATFORM), windows)
+  ifdef ALT_X11_PATH
+    X11_PATH = $(ALT_X11_PATH)
+  else
+    X11_PATH = /usr/X11R6
+  endif 
+
+  ifdef ALT_PACKAGE_PATH
+    PACKAGE_PATH = $(ALT_PACKAGE_PATH)
+  else
+    ifeq ($(PLATFORM), linux)
+      PACKAGE_PATH = /usr
+    else
+      PACKAGE_PATH = /usr/local
+    endif
+  endif
+endif
+
 #
 # Get platform definitions
 #
@@ -103,14 +121,6 @@
 endif # PROGRAM
 
 LDLIBS_COMMON += $(EXTRA_LIBS)
-
-ifneq ($(PLATFORM), windows)
-  ifdef ALT_X11_PATH
-    X11_PATH = $(ALT_X11_PATH)
-  else
-    X11_PATH = /usr/X11R6
-  endif 
-endif
 
 #
 # Default is to build, not import native binaries
diff -r 75576a3af8a1 make/common/shared/Defs-bsd.gmk
--- a/make/common/shared/Defs-bsd.gmk	Fri Dec 26 08:48:04 2008 -0800
+++ b/make/common/shared/Defs-bsd.gmk	Sun Jan 11 21:28:43 2009 -0500
@@ -54,7 +54,7 @@
 endef
 
 # Location on system where jdk installs might be
-USRJDKINSTANCES_PATH =/usr/lock
+USRJDKINSTANCES_PATH =$(PACKAGE_PATH)
 
 # UNIXCOMMAND_PATH: path to where the most common Unix commands are.
 #  NOTE: Must end with / so that it could be empty, allowing PATH usage.
@@ -107,7 +107,7 @@
 ifneq "$(origin ALT_DEVTOOLS_PATH)" "undefined"
   DEVTOOLS_PATH :=$(call PrefixPath,$(ALT_DEVTOOLS_PATH))
 else
-  DEVTOOLS_PATH =/usr/bin/
+  DEVTOOLS_PATH =$(PACKAGE_PATH)/bin/
 endif
 
 # _BOOTDIR1: First choice for a Bootstrap JDK, previous released JDK.
diff -r 75576a3af8a1 make/common/shared/Defs-utils.gmk
--- a/make/common/shared/Defs-utils.gmk	Fri Dec 26 08:48:04 2008 -0800
+++ b/make/common/shared/Defs-utils.gmk	Sun Jan 11 21:28:43 2009 -0500
@@ -57,7 +57,7 @@
   UTILS_COMMAND_PATH=$(UNIXCOMMAND_PATH)
   UTILS_USR_BIN_PATH=$(USRBIN_PATH)
   UTILS_CCS_BIN_PATH=$(USRBIN_PATH)
-  UTILS_DEVTOOL_PATH=$(USRBIN_PATH)
+  UTILS_DEVTOOL_PATH=$(DEVTOOLS_PATH)
 endif
 
 ifeq ($(PLATFORM),solaris)
@@ -78,11 +78,7 @@
 ADB            = $(UTILS_COMMAND_PATH)adb
 AR             = $(UTILS_CCS_BIN_PATH)ar
 AS             = $(UTILS_CCS_BIN_PATH)as
-ifeq ($(PLATFORM),bsd)
-BASENAME       = $(UTILS_USR_BIN_PATH)basename
-else
 BASENAME       = $(UTILS_COMMAND_PATH)basename
-endif
 CAT            = $(UTILS_COMMAND_PATH)cat
 CHMOD          = $(UTILS_COMMAND_PATH)chmod
 CMP            = $(UTILS_USR_BIN_PATH)cmp
@@ -97,11 +93,7 @@
 DIRNAME        = $(UTILS_USR_BIN_PATH)dirname
 ECHO           = $(UTILS_COMMAND_PATH)echo
 EGREP          = $(UTILS_COMMAND_PATH)egrep
-ifeq ($(PLATFORM),bsd)
-EXPR           = $(UTILS_COMMAND_PATH)expr
-else
 EXPR           = $(UTILS_USR_BIN_PATH)expr
-endif
 FILE           = $(UTILS_USR_BIN_PATH)file
 FIND           = $(UTILS_USR_BIN_PATH)find
 FMT            = $(UTILS_COMMAND_PATH)fmt
@@ -132,11 +124,7 @@
 RPM            = $(UTILS_COMMAND_PATH)rpm
 RPMBUILD       = $(UTILS_COMMAND_PATH)rpmbuild
 SCCS           = $(UTILS_CCS_BIN_PATH)sccs
-ifeq ($(PLATFORM),bsd)
-SED            = $(UTILS_USR_BIN_PATH)sed
-else
 SED            = $(UTILS_COMMAND_PATH)sed
-endif
 SH             = $(UTILS_COMMAND_PATH)sh
 SHOWREV        = $(UTILS_USR_BIN_PATH)showrev
 SORT           = $(UTILS_COMMAND_PATH)sort
@@ -144,11 +132,7 @@
 TAIL           = $(UTILS_USR_BIN_PATH)tail
 TAR            = $(UTILS_COMMAND_PATH)tar
 TEST           = $(UTILS_USR_BIN_PATH)test
-ifeq ($(PLATFORM),bsd)
-TOUCH          = $(UTILS_USR_BIN_PATH)touch
-else
 TOUCH          = $(UTILS_COMMAND_PATH)touch
-endif
 TR             = $(UTILS_USR_BIN_PATH)tr
 TRUE           = $(UTILS_COMMAND_PATH)true
 UNAME          = $(UTILS_COMMAND_PATH)uname
@@ -223,6 +207,32 @@
 endif
 
 # BSD specific
-ifeq ($(SYSTEM_UNAME),Darwin)
-  NAWK = $(USRBIN_PATH)awk
+ifeq ($(PLATFORM),bsd)
+  BASENAME     = $(UTILS_USR_BIN_PATH)basename
+  EGREP        = $(UTILS_USR_BIN_PATH)egrep
+  EXPR         = $(UTILS_COMMAND_PATH)expr
+  FMT          = $(UTILS_USR_BIN_PATH)fmt
+  GREP         = $(UTILS_USR_BIN_PATH)grep
+  GUNZIP       = $(UTILS_USR_BIN_PATH)gunzip
+  ID           = $(UTILS_USR_BIN_PATH)id
+  MSGFMT       = $(UTILS_DEVTOOL_PATH)msgfmt
+  SED          = $(UTILS_USR_BIN_PATH)sed
+  SORT         = $(UTILS_USR_BIN_PATH)sort
+  TEST         = $(UTILS_COMMAND_PATH)test
+  TOUCH        = $(UTILS_USR_BIN_PATH)touch
+  TRUE         = $(UTILS_USR_BIN_PATH)true
+  UNAME        = $(UTILS_USR_BIN_PATH)uname
+  # BSD OS_VENDOR specific
+  ifeq ($(OS_VENDOR), Apple)
+    NAWK       = $(UTILS_USR_BIN_PATH)awk
+    UNZIP      = $(UTILS_USR_BIN_PATH)unzip
+    UNZIPSFX   = $(UTILS_USR_BIN_PATH)unzipsfx
+    ZIP        = $(UTILS_USR_BIN_PATH)zip
+  else
+    UNZIP      = $(UTILS_DEVTOOL_PATH)unzip
+  endif
+  ifneq ($(OS_VENDOR), OpenBSD)
+    CPIO       = $(UTILS_USR_BIN_PATH)cpio
+    TAR        = $(UTILS_USR_BIN_PATH)tar
+  endif
 endif


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/bsd-port-dev/attachments/20090112/42ba108b/attachment.html 

From glewis at eyesbeyond.com  Mon Jan 12 21:21:29 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Tue, 13 Jan 2009 05:21:29 +0000
Subject: hg: bsd-port/bsd-port/jdk: 30 new changesets
Message-ID: <20090113052718.5BCC7D508@hg.openjdk.java.net>

Changeset: 94bcd3503668
Author:    bae
Date:      2008-07-25 14:46 +0400
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/94bcd3503668

6687968: PNGImageReader leaks native memory through an Inflater.
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java

Changeset: e62bc7b05b8a
Author:    igor
Date:      2008-08-04 18:50 +0400
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/e62bc7b05b8a

4356282: RFE: T2K should be used to rasterize CID/CFF fonts
Reviewed-by: bae, prr

! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/share/classes/sun/java2d/SunGraphicsEnvironment.java
! src/windows/native/sun/font/fontpath.c

Changeset: a56641c1f54e
Author:    tdv
Date:      2008-08-04 11:29 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/a56641c1f54e

6728834: D3D/OGL: LCD AA text becomes bold and blurred when rendering to a non-opaque destination
Reviewed-by: campbell

! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
+ test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java

Changeset: b2413144d908
Author:    tdv
Date:      2008-08-04 11:31 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/b2413144d908

6717988: D3D: rendering problems with JConsole on [Nvidia FX 5200]
Reviewed-by: campbell

! src/windows/native/sun/java2d/d3d/D3DBadHardware.h

Changeset: 06a02adcba4e
Author:    tdv
Date:      2008-08-05 09:37 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/06a02adcba4e

6733718: test /java/awt/FullScreen/UninitializedDisplayModeChangeTest/ fails
Reviewed-by: igor

+ test/java/awt/FullScreen/UninitializedDisplayModeChangeTest/DisplayModeChanger.java

Changeset: 15be3e891e97
Author:    jgodinez
Date:      2008-08-07 11:19 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/15be3e891e97

6731937: javax/print/CheckDupFlavor.java fails
Reviewed-by: campbell, tdv

! src/solaris/classes/sun/print/IPPPrintService.java
+ test/javax/print/CheckDupFlavor.java

Changeset: 3c4561f955f3
Author:    lana
Date:      2008-08-07 22:24 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3c4561f955f3

Merge

- make/tools/winver/Makefile
- make/tools/winver/bin/winver.exe
- make/tools/winver/src/StdAfx.cpp
- make/tools/winver/src/StdAfx.h
- make/tools/winver/src/winver.cpp
- src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java
- src/share/classes/javax/management/ToQueryString.java
! src/share/classes/sun/font/FontManager.java
! src/share/classes/sun/font/TrueTypeFont.java
! src/solaris/classes/sun/print/IPPPrintService.java
- test/javax/management/Introspector/LegacyIntrospectorTest.java

Changeset: 3d3ef4073bdd
Author:    jgodinez
Date:      2008-08-19 16:04 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3d3ef4073bdd

6731826: race condition in UnixPrintServiceLookup
Reviewed-by: campbell, tdv

! src/solaris/classes/sun/print/IPPPrintService.java
+ test/javax/print/TestRaceCond.java

Changeset: cd88b4ad7f25
Author:    tdv
Date:      2008-08-28 11:27 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/cd88b4ad7f25

6739267: D3D/OGL: add missing ThreeByteBgr to texture upload blit loop
Reviewed-by: campbell, flar

! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java
! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java
! src/share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
! src/share/native/sun/java2d/opengl/OGLBlitLoops.c
! src/share/native/sun/java2d/opengl/OGLSurfaceData.c
! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp
! src/windows/native/sun/java2d/d3d/D3DSurfaceData.h

Changeset: b8f91ea2fb33
Author:    tdv
Date:      2008-09-12 15:01 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/b8f91ea2fb33

6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal
Reviewed-by: prr, tdv
Contributed-by: rkennke at kennke.org

! src/share/classes/sun/java2d/SunGraphicsEnvironment.java
! src/share/classes/sun/swing/SwingUtilities2.java
! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
! src/solaris/native/sun/awt/fontpath.c
! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java

Changeset: 41ff3f84cd96
Author:    prr
Date:      2008-09-24 11:58 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/41ff3f84cd96

6751621: TextLayout.getBounds() doesn't account for strike through
Reviewed-by: igor, dougfelt

! src/share/classes/sun/font/Decoration.java
! src/share/classes/sun/font/Underline.java
+ test/java/awt/font/TextLayout/DecorationBoundsTest.java

Changeset: 3bc4d79d8123
Author:    tdv
Date:      2008-10-09 17:12 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3bc4d79d8123

6749060: LCD AA text rendered incorrectly when destination is non opaque (sw pipeline only)
Reviewed-by: campbell, prr

! src/share/classes/sun/java2d/SurfaceData.java
! test/sun/java2d/DirectX/NonOpaqueDestLCDAATest/NonOpaqueDestLCDAATest.java

Changeset: 9a6094d65d28
Author:    jgodinez
Date:      2008-10-13 15:41 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/9a6094d65d28

6732647: isAttributeValueSupported() is not consistant with getSupportedValues() for Copies, TEXT flavor
Reviewed-by: tdv, prr

! src/solaris/classes/sun/print/IPPPrintService.java
! src/solaris/classes/sun/print/UnixPrintService.java
! test/javax/print/attribute/PSCopiesFlavorTest.java

Changeset: 22d965ed3b93
Author:    prr
Date:      2008-10-16 06:28 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/22d965ed3b93

6751616: outline for underline in TextLayout with underline is off rasterized underline
Reviewed-by: dougfelt, igor

! src/share/classes/sun/font/Decoration.java
+ test/java/awt/font/TextLayout/UnderlinePositionTest.java

Changeset: 665850610378
Author:    lana
Date:      2008-10-20 11:52 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/665850610378

Merge

- make/ASSEMBLY_EXCEPTION
- make/LICENSE
- make/README
- make/README-builds.html
- make/README.html
- make/THIRD_PARTY_README
- make/java/nio/spp.sh
- make/tools/auto_multi/Makefile
- make/tools/src/build/tools/automulti/AutoMulti.java
- make/tools/src/build/tools/automulti/README.txt
- make/tools/src/build/tools/automulti/TestALFGenerator.java
- make/tools/src/build/tools/automulti/TestALFLookAndFeel.java
- src/share/classes/java/nio/channels/package.html
- src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java
- src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java
- src/share/classes/javax/swing/colorchooser/SyntheticImage.java
- src/share/classes/org/jcp/xml/dsig/internal/package.html
- src/share/classes/sun/launcher/LauncherHelp.java
- src/share/classes/sun/nio/ch/OptionAdaptor.java
- src/share/classes/sun/nio/ch/SocketOpts.java
- src/share/classes/sun/nio/ch/SocketOptsImpl.java
- src/share/classes/sun/nio/ch/exceptions
! src/share/classes/sun/swing/SwingUtilities2.java
- src/share/javavm/include/opcodes.h
- src/share/javavm/include/opcodes.length
- src/share/javavm/include/opcodes.list
- src/share/javavm/include/opcodes.weight
- src/share/javavm/include/opcodes.wide
- src/share/javavm/include/sys_api.h
- src/share/javavm/include/typedefs.h
- src/solaris/classes/sun/awt/motif/MButtonPeer.java
- src/solaris/classes/sun/awt/motif/MCanvasPeer.java
- src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java
- src/solaris/classes/sun/awt/motif/MCheckboxPeer.java
- src/solaris/classes/sun/awt/motif/MChoicePeer.java
- src/solaris/classes/sun/awt/motif/MComponentPeer.java
- src/solaris/classes/sun/awt/motif/MCustomCursor.java
- src/solaris/classes/sun/awt/motif/MDataTransferer.java
- src/solaris/classes/sun/awt/motif/MDialogPeer.java
- src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java
- src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java
- src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java
- src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java
- src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java
- src/solaris/classes/sun/awt/motif/MFileDialogPeer.java
- src/solaris/classes/sun/awt/motif/MFramePeer.java
- src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java
- src/solaris/classes/sun/awt/motif/MInputMethod.java
- src/solaris/classes/sun/awt/motif/MInputMethodControl.java
- src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java
- src/solaris/classes/sun/awt/motif/MLabelPeer.java
- src/solaris/classes/sun/awt/motif/MListPeer.java
- src/solaris/classes/sun/awt/motif/MMenuBarPeer.java
- src/solaris/classes/sun/awt/motif/MMenuItemPeer.java
- src/solaris/classes/sun/awt/motif/MMenuPeer.java
- src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java
- src/solaris/classes/sun/awt/motif/MPanelPeer.java
- src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java
- src/solaris/classes/sun/awt/motif/MRobotPeer.java
- src/solaris/classes/sun/awt/motif/MScrollPanePeer.java
- src/solaris/classes/sun/awt/motif/MScrollbarPeer.java
- src/solaris/classes/sun/awt/motif/MTextAreaPeer.java
- src/solaris/classes/sun/awt/motif/MTextFieldPeer.java
- src/solaris/classes/sun/awt/motif/MWindowPeer.java
- src/solaris/classes/sun/awt/motif/X11Clipboard.java
- src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java
- src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java
- src/solaris/classes/sun/awt/motif/X11Selection.java
- src/solaris/classes/sun/awt/motif/X11SelectionHolder.java
- src/solaris/javavm/include/typedefs_md.h
- src/solaris/native/sun/awt/awt_Button.c
- src/solaris/native/sun/awt/awt_Canvas.c
- src/solaris/native/sun/awt/awt_Checkbox.c
- src/solaris/native/sun/awt/awt_Choice12.c
- src/solaris/native/sun/awt/awt_Choice21.c
- src/solaris/native/sun/awt/awt_Component.c
- src/solaris/native/sun/awt/awt_Cursor.c
- src/solaris/native/sun/awt/awt_DataTransferer.c
- src/solaris/native/sun/awt/awt_DataTransferer.h
- src/solaris/native/sun/awt/awt_FileDialog.c
- src/solaris/native/sun/awt/awt_GlobalCursorManager.c
- src/solaris/native/sun/awt/awt_KeyboardFocusManager.c
- src/solaris/native/sun/awt/awt_Label.c
- src/solaris/native/sun/awt/awt_List.c
- src/solaris/native/sun/awt/awt_Menu.c
- src/solaris/native/sun/awt/awt_Menu.h
- src/solaris/native/sun/awt/awt_MenuBar.c
- src/solaris/native/sun/awt/awt_MenuBar.h
- src/solaris/native/sun/awt/awt_MenuComponent.c
- src/solaris/native/sun/awt/awt_MenuItem.c
- src/solaris/native/sun/awt/awt_PopupMenu.c
- src/solaris/native/sun/awt/awt_ScrollPane.c
- src/solaris/native/sun/awt/awt_Scrollbar.c
- src/solaris/native/sun/awt/awt_Selection.c
- src/solaris/native/sun/awt/awt_TextArea.c
- src/solaris/native/sun/awt/awt_TextArea.h
- src/solaris/native/sun/awt/awt_TextField.c
- src/solaris/native/sun/awt/awt_TextField.h
- src/solaris/native/sun/awt/awt_TopLevel.c
- src/solaris/native/sun/awt/awt_XmDnD.c
- src/solaris/native/sun/awt/awt_XmDnD.h
- src/solaris/native/sun/awt/awt_dnd.c
- src/solaris/native/sun/awt/awt_dnd.h
- src/solaris/native/sun/awt/awt_dnd_ds.c
- src/solaris/native/sun/awt/awt_dnd_dt.c
- src/solaris/native/sun/awt/awt_motif.c
- src/solaris/native/sun/awt/awt_motif12.c
- src/solaris/native/sun/awt/awt_motif21.c
- src/solaris/native/sun/awt/awt_xembed.c
- src/solaris/native/sun/awt/canvas.c
- src/solaris/native/sun/awt/cursor.c
- src/windows/javavm/include/typedefs_md.h
- test/javax/swing/JFileChooser/4252173/bug4252173.java
- test/javax/swing/JFileChooser/6524424/bug6524424.html
- test/javax/swing/JFileChooser/6524424/bug6524424.java
- test/sun/net/www/http/ChunkedInputStream/test.txt
- test/tools/launcher/Arrrghs.sh

Changeset: 452c58b2f533
Author:    tdv
Date:      2008-10-21 08:25 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/452c58b2f533

6755274: 6u10b33 2d tests fails on sles10x64 with jvm crash
Reviewed-by: campbell

! src/solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
! src/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java

Changeset: c739feb28074
Author:    prr
Date:      2008-10-28 14:40 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/c739feb28074

6764543: SIGSEGV in libfontconfig.so starting from jdk7b33
Reviewed-by: campbell, igor

! src/solaris/native/sun/awt/fontpath.c

Changeset: 594c52582b21
Author:    tdv
Date:      2008-10-28 14:47 -0700
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/594c52582b21

6764257: D3D/OGL: color is not reset properly after save/restoreState() [RSL]
Reviewed-by: campbell

! src/share/classes/sun/java2d/pipe/BufferedContext.java
+ test/sun/java2d/pipe/hw/RSLContextInvalidationTest/RSLContextInvalidationTest.java

Changeset: 9cdababf6179
Author:    igor
Date:      2008-10-29 01:52 +0300
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/9cdababf6179

6761856: OpenJDK: vertical text metrics may be significanly different from those returned by Sun JDK
Reviewed-by: bae, prr

! src/share/native/sun/font/freetypeScaler.c
! test/java/awt/font/TextLayout/TextLayoutBounds.java

Changeset: 3a9d06af8830
Author:    bae
Date:      2008-11-01 20:42 +0300
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3a9d06af8830

6541476: PNG imageio plugin incorrectly handles iTXt chunk
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
+ test/javax/imageio/plugins/png/ITXtTest.java

Changeset: 8eb24fc88242
Author:    tdv
Date:      2008-11-18 17:16 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/8eb24fc88242

6758179: D3D: AlphaComposite is applied incorrectly for uncached opaque BufferedImage
Reviewed-by: campbell, flar

! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp
+ test/sun/java2d/DirectX/OpaqueImageToSurfaceBlitTest/OpaqueImageToSurfaceBlitTest.java

Changeset: 3fea7e660a8f
Author:    tdv
Date:      2008-11-18 18:32 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3fea7e660a8f

6757527: D3D: serious rendering issues on Nvidia boards with driver version 178.13 on Vista
Reviewed-by: campbell

! src/windows/native/sun/java2d/d3d/D3DBlitLoops.cpp
! src/windows/native/sun/java2d/d3d/D3DContext.cpp

Changeset: be363ea85cb4
Author:    jgodinez
Date:      2008-11-25 14:38 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/be363ea85cb4

6653384: Variable "initialized" in class CUPSPrinter is static by mistake
Reviewed-by: tdv, prr

! src/solaris/classes/sun/print/CUPSPrinter.java
! src/solaris/classes/sun/print/IPPPrintService.java
+ test/java/awt/print/PrinterJob/GetMediasTest.java

Changeset: c8eea39734e8
Author:    jgodinez
Date:      2008-12-04 10:05 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/c8eea39734e8

6587245: Import declaration not used in sun.print.*
Reviewed-by: tdv, prr

! src/share/classes/javax/print/Doc.java
! src/share/classes/javax/print/DocFlavor.java
! src/share/classes/javax/print/DocPrintJob.java
! src/share/classes/javax/print/MultiDocPrintService.java
! src/share/classes/javax/print/PrintServiceLookup.java
! src/share/classes/javax/print/attribute/URISyntax.java
! src/share/classes/javax/print/event/PrintServiceAttributeEvent.java
! src/share/classes/sun/print/PSPathGraphics.java
! src/share/classes/sun/print/PrintJobAttributeException.java
! src/share/classes/sun/print/SunMinMaxPage.java
! src/share/classes/sun/print/SunPageSelection.java

Changeset: 15435c60c751
Author:    tdv
Date:      2008-12-04 11:21 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/15435c60c751

6708580: Java applications slow when EXA enabled
Reviewed-by: prr, tdv
Contributed-by: ceisserer <linuxhippy at gmail.com>

! make/sun/awt/mapfile-mawt-vers
! make/sun/xawt/mapfile-vers
! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java
! src/solaris/native/sun/java2d/x11/X11SurfaceData.c

Changeset: b0c446712fae
Author:    jgodinez
Date:      2008-12-08 10:23 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/b0c446712fae

6665212: PrinterJob class, method lookupStreamPrintServices(), "fos" in docs is unknown
Reviewed-by: tdv, prr

! src/share/classes/java/awt/print/PrinterJob.java

Changeset: b163d898f83f
Author:    tdv
Date:      2008-12-08 17:04 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/b163d898f83f

6772137: D3D: Dragging the scroll bar of a JScrollPane containing a JTree causes incorrect red
Reviewed-by: campbell

! src/windows/native/sun/java2d/d3d/D3DBadHardware.h

Changeset: bf5dd3128c6a
Author:    lana
Date:      2008-12-08 19:49 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/bf5dd3128c6a

Merge


Changeset: 50c67678b0d1
Author:    lana
Date:      2009-01-06 16:24 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/50c67678b0d1

Merge

! src/share/classes/sun/swing/SwingUtilities2.java

Changeset: 8663c12b4c56
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-12 21:15 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/8663c12b4c56

. Merge from main OpenJDK repository.

! src/share/classes/sun/java2d/SunGraphicsEnvironment.java
! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
! src/solaris/native/sun/awt/fontpath.c
! src/solaris/native/sun/java2d/x11/X11SurfaceData.c



From glewis at eyesbeyond.com  Mon Jan 12 21:34:18 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Mon, 12 Jan 2009 21:34:18 -0800
Subject: jdk: Path corrections (utils & cups)
In-Reply-To: <200901121547.26589.kurt@intricatesoftware.com>
References: <200901121547.26589.kurt@intricatesoftware.com>
Message-ID: <20090113053418.GA24170@misty.eyesbeyond.com>

On Mon, Jan 12, 2009 at 03:47:26PM -0500, Kurt Miller wrote:
> The following diff cleans up paths for utils defined Def-utils.gmk
> as well as setting the correct default cups headers path for Apple.
> 
> I have tested it on OpenBSD and FreeBSD but I don't have OS X on
> x86 to do a test build. However, I carefully checked the paths on
> my Lepoard/ppc laptop to ensure they are correct for Apple too.

They look right for Leopard/x86 too, although I haven't had time to
try them.

> - Set DEVTOOLS_PATH to $(PACKAGE_PATH)/bin/ which is the correct
>   location for tools that don't come preinstalled with the platform.

D'oh, I always thought this was the path to gcc/g++, but you're right.

> - Set _CUPS_HEADERS_PATH correctly for Apple which comes
>   with cups.
> - Set up full paths to utils defined in Defs-utils.gmk
>   for bsd with exceptions for OS_VENDOR differences.

Looks good.  Minor comments below.

> --- a/make/common/shared/Defs-utils.gmk	Sat Jan 10 22:13:03 2009 -0500
> +++ b/make/common/shared/Defs-utils.gmk	Sun Jan 11 21:30:19 2009 -0500
> @@ -64,6 +64,13 @@
>    UTILS_COMMAND_PATH=$(UNIXCOMMAND_PATH)
>    UTILS_USR_BIN_PATH=$(UNIXCOMMAND_PATH)
>    UTILS_CCS_BIN_PATH=$(UNIXCOMMAND_PATH)
> +  UTILS_DEVTOOL_PATH=$(DEVTOOLS_PATH)
> +endif
> +
> +ifeq ($(PLATFORM),bsd)
> +  UTILS_COMMAND_PATH=$(UNIXCOMMAND_PATH)
> +  UTILS_USR_BIN_PATH=$(USRBIN_PATH)
> +  UTILS_CCS_BIN_PATH=$(USRBIN_PATH)
>    UTILS_DEVTOOL_PATH=$(DEVTOOLS_PATH)
>  endif
>  
> @@ -202,6 +209,32 @@
>  endif
>  
>  # BSD specific
> -ifeq ($(SYSTEM_UNAME),Darwin)
> -  NAWK = $(USRBIN_PATH)awk
> +ifeq ($(PLATFORM),bsd)
> +  BASENAME     = $(UTILS_USR_BIN_PATH)basename
> +  EGREP        = $(UTILS_USR_BIN_PATH)egrep
> +  EXPR         = $(UTILS_COMMAND_PATH)expr
> +  FMT          = $(UTILS_USR_BIN_PATH)fmt
> +  GREP         = $(UTILS_USR_BIN_PATH)grep
> +  GUNZIP       = $(UTILS_USR_BIN_PATH)gunzip
> +  ID           = $(UTILS_USR_BIN_PATH)id
> +  MSGFMT       = $(UTILS_DEVTOOL_PATH)msgfmt
> +  SED          = $(UTILS_USR_BIN_PATH)sed
> +  SORT         = $(UTILS_USR_BIN_PATH)sort
> +  TEST         = $(UTILS_COMMAND_PATH)test
> +  TOUCH        = $(UTILS_USR_BIN_PATH)touch
> +  TRUE         = $(UTILS_USR_BIN_PATH)true
> +  UNAME        = $(UTILS_USR_BIN_PATH)uname
> +  # BSD OS_VENDOR specific
> +  ifeq ($(OS_VENDOR), Apple)
> +    NAWK       = $(UTILS_USR_BIN_PATH)awk
> +    UNZIP      = $(UTILS_USR_BIN_PATH)unzip

NAWK and UNZIP for Apple are the same as the default, so they don't need
to be overridden.

> +    UNZIPSFX   = $(UTILS_USR_BIN_PATH)unzipsfx
> +    ZIP        = $(UTILS_USR_BIN_PATH)zip

This should be ZIPEXE based on the default variables.

> +  else
> +    UNZIP      = $(UTILS_DEVTOOL_PATH)unzip
> +  endif
> +  ifneq ($(OS_VENDOR), OpenBSD)
> +    CPIO       = $(UTILS_USR_BIN_PATH)cpio
> +    TAR        = $(UTILS_USR_BIN_PATH)tar
> +  endif
>  endif

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From glewis at eyesbeyond.com  Mon Jan 12 21:36:14 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Mon, 12 Jan 2009 21:36:14 -0800
Subject: corba: Path corrections (utils & misc others)
In-Reply-To: <200901121550.04514.kurt@intricatesoftware.com>
References: <200901121550.04514.kurt@intricatesoftware.com>
Message-ID: <20090113053614.GB24170@misty.eyesbeyond.com>

On Mon, Jan 12, 2009 at 03:50:04PM -0500, Kurt Miller wrote:
> The following diff cleans up paths for utils defined Def-utils.gmk
> and sets other paths to be consistant with the jdk tree's version
> of them.
> 
> Tested the same as the jdk version of the diff. i.e. Test builds
> on OpenBSD and FreeBSD, by inspection on Apple.
> 
> - Sync Defs.gmk with jdk version by defining PACKAGE_PATH and moving
>   the X11_PATH definition to before including platform definitions.
> - Set DEVTOOLS_PATH to $(PACKAGE_PATH)/bin/ which is the correct
>   location for tools that don't come preinstalled with the platform.
> - Sync USRJDKINSTANCES_PATH to match the corresponding jdk value.
> - Set up full paths to utils defined in Defs-utils.gmk
>   for bsd with exceptions for OS_VENDOR differences.

Looks good.  Same minor comments as per the jdk changes.

Thanks for doing this!

> diff -r 75576a3af8a1 make/common/Defs.gmk
> --- a/make/common/Defs.gmk	Fri Dec 26 08:48:04 2008 -0800
> +++ b/make/common/Defs.gmk	Sun Jan 11 21:28:43 2009 -0500
> @@ -53,6 +53,24 @@
>  
>  _OUTPUTDIR=$(TOPDIR)/build/$(PLATFORM)-$(ARCH)
>  
> +ifneq ($(PLATFORM), windows)
> +  ifdef ALT_X11_PATH
> +    X11_PATH = $(ALT_X11_PATH)
> +  else
> +    X11_PATH = /usr/X11R6
> +  endif 
> +
> +  ifdef ALT_PACKAGE_PATH
> +    PACKAGE_PATH = $(ALT_PACKAGE_PATH)
> +  else
> +    ifeq ($(PLATFORM), linux)
> +      PACKAGE_PATH = /usr
> +    else
> +      PACKAGE_PATH = /usr/local
> +    endif
> +  endif
> +endif
> +
>  #
>  # Get platform definitions
>  #
> @@ -103,14 +121,6 @@
>  endif # PROGRAM
>  
>  LDLIBS_COMMON += $(EXTRA_LIBS)
> -
> -ifneq ($(PLATFORM), windows)
> -  ifdef ALT_X11_PATH
> -    X11_PATH = $(ALT_X11_PATH)
> -  else
> -    X11_PATH = /usr/X11R6
> -  endif 
> -endif
>  
>  #
>  # Default is to build, not import native binaries
> diff -r 75576a3af8a1 make/common/shared/Defs-bsd.gmk
> --- a/make/common/shared/Defs-bsd.gmk	Fri Dec 26 08:48:04 2008 -0800
> +++ b/make/common/shared/Defs-bsd.gmk	Sun Jan 11 21:28:43 2009 -0500
> @@ -54,7 +54,7 @@
>  endef
>  
>  # Location on system where jdk installs might be
> -USRJDKINSTANCES_PATH =/usr/lock
> +USRJDKINSTANCES_PATH =$(PACKAGE_PATH)
>  
>  # UNIXCOMMAND_PATH: path to where the most common Unix commands are.
>  #  NOTE: Must end with / so that it could be empty, allowing PATH usage.
> @@ -107,7 +107,7 @@
>  ifneq "$(origin ALT_DEVTOOLS_PATH)" "undefined"
>    DEVTOOLS_PATH :=$(call PrefixPath,$(ALT_DEVTOOLS_PATH))
>  else
> -  DEVTOOLS_PATH =/usr/bin/
> +  DEVTOOLS_PATH =$(PACKAGE_PATH)/bin/
>  endif
>  
>  # _BOOTDIR1: First choice for a Bootstrap JDK, previous released JDK.
> diff -r 75576a3af8a1 make/common/shared/Defs-utils.gmk
> --- a/make/common/shared/Defs-utils.gmk	Fri Dec 26 08:48:04 2008 -0800
> +++ b/make/common/shared/Defs-utils.gmk	Sun Jan 11 21:28:43 2009 -0500
> @@ -57,7 +57,7 @@
>    UTILS_COMMAND_PATH=$(UNIXCOMMAND_PATH)
>    UTILS_USR_BIN_PATH=$(USRBIN_PATH)
>    UTILS_CCS_BIN_PATH=$(USRBIN_PATH)
> -  UTILS_DEVTOOL_PATH=$(USRBIN_PATH)
> +  UTILS_DEVTOOL_PATH=$(DEVTOOLS_PATH)
>  endif
>  
>  ifeq ($(PLATFORM),solaris)
> @@ -78,11 +78,7 @@
>  ADB            = $(UTILS_COMMAND_PATH)adb
>  AR             = $(UTILS_CCS_BIN_PATH)ar
>  AS             = $(UTILS_CCS_BIN_PATH)as
> -ifeq ($(PLATFORM),bsd)
> -BASENAME       = $(UTILS_USR_BIN_PATH)basename
> -else
>  BASENAME       = $(UTILS_COMMAND_PATH)basename
> -endif
>  CAT            = $(UTILS_COMMAND_PATH)cat
>  CHMOD          = $(UTILS_COMMAND_PATH)chmod
>  CMP            = $(UTILS_USR_BIN_PATH)cmp
> @@ -97,11 +93,7 @@
>  DIRNAME        = $(UTILS_USR_BIN_PATH)dirname
>  ECHO           = $(UTILS_COMMAND_PATH)echo
>  EGREP          = $(UTILS_COMMAND_PATH)egrep
> -ifeq ($(PLATFORM),bsd)
> -EXPR           = $(UTILS_COMMAND_PATH)expr
> -else
>  EXPR           = $(UTILS_USR_BIN_PATH)expr
> -endif
>  FILE           = $(UTILS_USR_BIN_PATH)file
>  FIND           = $(UTILS_USR_BIN_PATH)find
>  FMT            = $(UTILS_COMMAND_PATH)fmt
> @@ -132,11 +124,7 @@
>  RPM            = $(UTILS_COMMAND_PATH)rpm
>  RPMBUILD       = $(UTILS_COMMAND_PATH)rpmbuild
>  SCCS           = $(UTILS_CCS_BIN_PATH)sccs
> -ifeq ($(PLATFORM),bsd)
> -SED            = $(UTILS_USR_BIN_PATH)sed
> -else
>  SED            = $(UTILS_COMMAND_PATH)sed
> -endif
>  SH             = $(UTILS_COMMAND_PATH)sh
>  SHOWREV        = $(UTILS_USR_BIN_PATH)showrev
>  SORT           = $(UTILS_COMMAND_PATH)sort
> @@ -144,11 +132,7 @@
>  TAIL           = $(UTILS_USR_BIN_PATH)tail
>  TAR            = $(UTILS_COMMAND_PATH)tar
>  TEST           = $(UTILS_USR_BIN_PATH)test
> -ifeq ($(PLATFORM),bsd)
> -TOUCH          = $(UTILS_USR_BIN_PATH)touch
> -else
>  TOUCH          = $(UTILS_COMMAND_PATH)touch
> -endif
>  TR             = $(UTILS_USR_BIN_PATH)tr
>  TRUE           = $(UTILS_COMMAND_PATH)true
>  UNAME          = $(UTILS_COMMAND_PATH)uname
> @@ -223,6 +207,32 @@
>  endif
>  
>  # BSD specific
> -ifeq ($(SYSTEM_UNAME),Darwin)
> -  NAWK = $(USRBIN_PATH)awk
> +ifeq ($(PLATFORM),bsd)
> +  BASENAME     = $(UTILS_USR_BIN_PATH)basename
> +  EGREP        = $(UTILS_USR_BIN_PATH)egrep
> +  EXPR         = $(UTILS_COMMAND_PATH)expr
> +  FMT          = $(UTILS_USR_BIN_PATH)fmt
> +  GREP         = $(UTILS_USR_BIN_PATH)grep
> +  GUNZIP       = $(UTILS_USR_BIN_PATH)gunzip
> +  ID           = $(UTILS_USR_BIN_PATH)id
> +  MSGFMT       = $(UTILS_DEVTOOL_PATH)msgfmt
> +  SED          = $(UTILS_USR_BIN_PATH)sed
> +  SORT         = $(UTILS_USR_BIN_PATH)sort
> +  TEST         = $(UTILS_COMMAND_PATH)test
> +  TOUCH        = $(UTILS_USR_BIN_PATH)touch
> +  TRUE         = $(UTILS_USR_BIN_PATH)true
> +  UNAME        = $(UTILS_USR_BIN_PATH)uname
> +  # BSD OS_VENDOR specific
> +  ifeq ($(OS_VENDOR), Apple)
> +    NAWK       = $(UTILS_USR_BIN_PATH)awk
> +    UNZIP      = $(UTILS_USR_BIN_PATH)unzip
> +    UNZIPSFX   = $(UTILS_USR_BIN_PATH)unzipsfx
> +    ZIP        = $(UTILS_USR_BIN_PATH)zip
> +  else
> +    UNZIP      = $(UTILS_DEVTOOL_PATH)unzip
> +  endif
> +  ifneq ($(OS_VENDOR), OpenBSD)
> +    CPIO       = $(UTILS_USR_BIN_PATH)cpio
> +    TAR        = $(UTILS_USR_BIN_PATH)tar
> +  endif
>  endif

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From mvfranz at gmail.com  Tue Jan 13 16:37:00 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Tue, 13 Jan 2009 19:37:00 -0500
Subject: hg: bsd-port/bsd-port/jdk: 30 new changesets
In-Reply-To: <20090113052718.5BCC7D508@hg.openjdk.java.net>
References: <20090113052718.5BCC7D508@hg.openjdk.java.net>
Message-ID: <fee4d890901131637n19ed38eby3bcb95fc8f96a661@mail.gmail.com>

Greg,

Are there any patches in the queue that will resolve the OS X build issues
related to intptr_t/int32_t/int64_t?

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090113/9a30c52b/attachment.html 

From glewis at eyesbeyond.com  Tue Jan 13 17:50:19 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Tue, 13 Jan 2009 17:50:19 -0800
Subject: hg: bsd-port/bsd-port/jdk: 30 new changesets
In-Reply-To: <fee4d890901131637n19ed38eby3bcb95fc8f96a661@mail.gmail.com>
References: <20090113052718.5BCC7D508@hg.openjdk.java.net>
	<fee4d890901131637n19ed38eby3bcb95fc8f96a661@mail.gmail.com>
Message-ID: <20090114015019.GA68719@misty.eyesbeyond.com>

On Tue, Jan 13, 2009 at 07:37:00PM -0500, Michael Franz wrote:
> Are there any patches in the queue that will resolve the OS X build issues
> related to intptr_t/int32_t/int64_t?

Nope :(.  I saw those changes got merged into the HotSpot repository the
other day, but they haven't been merged up into the main OpenJDK repository
we pull from yet :(.

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From kurt at intricatesoftware.com  Tue Jan 13 20:00:29 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Wed, 14 Jan 2009 04:00:29 +0000
Subject: hg: bsd-port/bsd-port/hotspot: Summary: Use g++ for dynmain linking
	of libjvm
Message-ID: <20090114040034.AA486D633@hg.openjdk.java.net>

Changeset: 934aeb6514ae
Author:    kurt
Date:      2009-01-13 22:57 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/934aeb6514ae

Summary: Use g++ for dynmain linking of libjvm
Reviewed By: Xiaobin

Correct undefined symbols noted on OpenBSD using
gcc 3.3.5 when using gcc to link libjvm combined
with version scripts.

! make/bsd/makefiles/vm.make



From kurt at intricatesoftware.com  Wed Jan 14 08:56:05 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Wed, 14 Jan 2009 16:56:05 +0000
Subject: hg: bsd-port/bsd-port/hotspot: Summary: Use current datasize rlimit
	instead of max for OpenBSD
Message-ID: <20090114165607.AF234D667@hg.openjdk.java.net>

Changeset: 36e8a25a0058
Author:    kurt
Date:      2009-01-14 11:53 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/36e8a25a0058

Summary: Use current datasize rlimit instead of max for OpenBSD

! src/os/bsd/vm/os_bsd.cpp



From kurt at intricatesoftware.com  Wed Jan 14 09:10:51 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Wed, 14 Jan 2009 12:10:51 -0500
Subject: jdk: Path corrections (utils & cups)
In-Reply-To: <20090113053418.GA24170@misty.eyesbeyond.com>
References: <200901121547.26589.kurt@intricatesoftware.com>
	<20090113053418.GA24170@misty.eyesbeyond.com>
Message-ID: <496E1C9B.1040702@intricatesoftware.com>

Hi Greg,

Greg Lewis wrote:
>> +  TRUE         = $(UTILS_USR_BIN_PATH)true
>> +  UNAME        = $(UTILS_USR_BIN_PATH)uname
>> +  # BSD OS_VENDOR specific
>> +  ifeq ($(OS_VENDOR), Apple)
>> +    NAWK       = $(UTILS_USR_BIN_PATH)awk
>> +    UNZIP      = $(UTILS_USR_BIN_PATH)unzip
> 
> NAWK and UNZIP for Apple are the same as the default, so they don't need
> to be overridden.

OS X doesn't have nawk but instead just awk. You are
correct about UNZIP, I missed the path was default.

>> +    UNZIPSFX   = $(UTILS_USR_BIN_PATH)unzipsfx
>> +    ZIP        = $(UTILS_USR_BIN_PATH)zip
> 
> This should be ZIPEXE based on the default variables.

Yes. Good catch, thank you.

>> +  else
>> +    UNZIP      = $(UTILS_DEVTOOL_PATH)unzip
>> +  endif
>> +  ifneq ($(OS_VENDOR), OpenBSD)
>> +    CPIO       = $(UTILS_USR_BIN_PATH)cpio
>> +    TAR        = $(UTILS_USR_BIN_PATH)tar
>> +  endif
>>  endif

The update diff is attached.

Thanks,
-Kurt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jdkpaths.diff
Url: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090114/25f4bd8e/jdkpaths.diff 

From kurt at intricatesoftware.com  Wed Jan 14 09:15:27 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Wed, 14 Jan 2009 12:15:27 -0500
Subject: corba: Path corrections (utils & misc others)
In-Reply-To: <20090113053614.GB24170@misty.eyesbeyond.com>
References: <200901121550.04514.kurt@intricatesoftware.com>
	<20090113053614.GB24170@misty.eyesbeyond.com>
Message-ID: <496E1DAF.2050001@intricatesoftware.com>

Hi Greg.

Greg Lewis wrote:
> On Mon, Jan 12, 2009 at 03:50:04PM -0500, Kurt Miller wrote:
>> The following diff cleans up paths for utils defined Def-utils.gmk
>> and sets other paths to be consistant with the jdk tree's version
>> of them.
>>
>> Tested the same as the jdk version of the diff. i.e. Test builds
>> on OpenBSD and FreeBSD, by inspection on Apple.
>>
>> - Sync Defs.gmk with jdk version by defining PACKAGE_PATH and moving
>>   the X11_PATH definition to before including platform definitions.
>> - Set DEVTOOLS_PATH to $(PACKAGE_PATH)/bin/ which is the correct
>>   location for tools that don't come preinstalled with the platform.
>> - Sync USRJDKINSTANCES_PATH to match the corresponding jdk value.
>> - Set up full paths to utils defined in Defs-utils.gmk
>>   for bsd with exceptions for OS_VENDOR differences.
> 
> Looks good.  Same minor comments as per the jdk changes.
> 
> Thanks for doing this!

Thanks for the reviews! :-)

Update diff attached.

-Kurt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: corbapaths.diff
Url: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090114/aaf85206/corbapaths.diff 

From glewis at eyesbeyond.com  Wed Jan 14 10:28:42 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Wed, 14 Jan 2009 10:28:42 -0800
Subject: jdk: Path corrections (utils & cups)
In-Reply-To: <496E1C9B.1040702@intricatesoftware.com>
References: <200901121547.26589.kurt@intricatesoftware.com>
	<20090113053418.GA24170@misty.eyesbeyond.com>
	<496E1C9B.1040702@intricatesoftware.com>
Message-ID: <20090114182842.GA10441@misty.eyesbeyond.com>

G'day Kurt,

On Wed, Jan 14, 2009 at 12:10:51PM -0500, Kurt Miller wrote:
> Greg Lewis wrote:
> >> +  TRUE         = $(UTILS_USR_BIN_PATH)true
> >> +  UNAME        = $(UTILS_USR_BIN_PATH)uname
> >> +  # BSD OS_VENDOR specific
> >> +  ifeq ($(OS_VENDOR), Apple)
> >> +    NAWK       = $(UTILS_USR_BIN_PATH)awk
> >> +    UNZIP      = $(UTILS_USR_BIN_PATH)unzip
> > 
> > NAWK and UNZIP for Apple are the same as the default, so they don't need
> > to be overridden.
> 
> OS X doesn't have nawk but instead just awk. You are
> correct about UNZIP, I missed the path was default.

D'oh, I missed the nawk/awk difference.

> >> +    UNZIPSFX   = $(UTILS_USR_BIN_PATH)unzipsfx
> >> +    ZIP        = $(UTILS_USR_BIN_PATH)zip
> > 
> > This should be ZIPEXE based on the default variables.
> 
> Yes. Good catch, thank you.
> 
> >> +  else
> >> +    UNZIP      = $(UTILS_DEVTOOL_PATH)unzip
> >> +  endif
> >> +  ifneq ($(OS_VENDOR), OpenBSD)
> >> +    CPIO       = $(UTILS_USR_BIN_PATH)cpio
> >> +    TAR        = $(UTILS_USR_BIN_PATH)tar
> >> +  endif
> >>  endif
> 
> The update diff is attached.

I think this and the other updated diff are fine to commit, fwiw.

> diff -r 8663c12b4c56 make/common/shared/Defs-bsd.gmk
> --- a/make/common/shared/Defs-bsd.gmk	Mon Jan 12 21:15:53 2009 -0800
> +++ b/make/common/shared/Defs-bsd.gmk	Tue Jan 13 21:42:12 2009 -0500
> @@ -107,7 +107,7 @@
>  ifneq "$(origin ALT_DEVTOOLS_PATH)" "undefined"
>    DEVTOOLS_PATH :=$(call PrefixPath,$(ALT_DEVTOOLS_PATH))
>  else
> -  DEVTOOLS_PATH =/usr/bin/
> +  DEVTOOLS_PATH =$(PACKAGE_PATH)/bin/
>  endif
>  
>  # _BOOTDIR1: First choice for a Bootstrap JDK, previous released JDK.
> @@ -121,7 +121,11 @@
>  BUILD_HEADLESS = true
>  LIBM=-lm
>  
> -_CUPS_HEADERS_PATH=$(PACKAGE_PATH)/include
> +ifeq ($(OS_VENDOR), Apple)
> +  _CUPS_HEADERS_PATH=/usr/include
> +else
> +  _CUPS_HEADERS_PATH=$(PACKAGE_PATH)/include
> +endif
>  
>  # Import JDK images allow for partial builds, components not built are
>  #    imported (or copied from) these import areas when needed.
> diff -r 8663c12b4c56 make/common/shared/Defs-utils.gmk
> --- a/make/common/shared/Defs-utils.gmk	Mon Jan 12 21:15:53 2009 -0800
> +++ b/make/common/shared/Defs-utils.gmk	Tue Jan 13 21:42:12 2009 -0500
> @@ -64,6 +64,13 @@
>    UTILS_COMMAND_PATH=$(UNIXCOMMAND_PATH)
>    UTILS_USR_BIN_PATH=$(UNIXCOMMAND_PATH)
>    UTILS_CCS_BIN_PATH=$(UNIXCOMMAND_PATH)
> +  UTILS_DEVTOOL_PATH=$(DEVTOOLS_PATH)
> +endif
> +
> +ifeq ($(PLATFORM),bsd)
> +  UTILS_COMMAND_PATH=$(UNIXCOMMAND_PATH)
> +  UTILS_USR_BIN_PATH=$(USRBIN_PATH)
> +  UTILS_CCS_BIN_PATH=$(USRBIN_PATH)
>    UTILS_DEVTOOL_PATH=$(DEVTOOLS_PATH)
>  endif
>  
> @@ -202,6 +209,31 @@
>  endif
>  
>  # BSD specific
> -ifeq ($(SYSTEM_UNAME),Darwin)
> -  NAWK = $(USRBIN_PATH)awk
> +ifeq ($(PLATFORM),bsd)
> +  BASENAME     = $(UTILS_USR_BIN_PATH)basename
> +  EGREP        = $(UTILS_USR_BIN_PATH)egrep
> +  EXPR         = $(UTILS_COMMAND_PATH)expr
> +  FMT          = $(UTILS_USR_BIN_PATH)fmt
> +  GREP         = $(UTILS_USR_BIN_PATH)grep
> +  GUNZIP       = $(UTILS_USR_BIN_PATH)gunzip
> +  ID           = $(UTILS_USR_BIN_PATH)id
> +  MSGFMT       = $(UTILS_DEVTOOL_PATH)msgfmt
> +  SED          = $(UTILS_USR_BIN_PATH)sed
> +  SORT         = $(UTILS_USR_BIN_PATH)sort
> +  TEST         = $(UTILS_COMMAND_PATH)test
> +  TOUCH        = $(UTILS_USR_BIN_PATH)touch
> +  TRUE         = $(UTILS_USR_BIN_PATH)true
> +  UNAME        = $(UTILS_USR_BIN_PATH)uname
> +  # BSD OS_VENDOR specific
> +  ifeq ($(OS_VENDOR), Apple)
> +    NAWK       = $(UTILS_USR_BIN_PATH)awk
> +    UNZIPSFX   = $(UTILS_USR_BIN_PATH)unzipsfx
> +    ZIPEXE     = $(UTILS_USR_BIN_PATH)zip
> +  else
> +    UNZIP      = $(UTILS_DEVTOOL_PATH)unzip
> +  endif
> +  ifneq ($(OS_VENDOR), OpenBSD)
> +    CPIO       = $(UTILS_USR_BIN_PATH)cpio
> +    TAR        = $(UTILS_USR_BIN_PATH)tar
> +  endif
>  endif


-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From kurt at intricatesoftware.com  Wed Jan 14 10:41:14 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Wed, 14 Jan 2009 13:41:14 -0500
Subject: hotspot: Use DEFAULT_LIBPATH from build env
Message-ID: <200901141341.15110.kurt@intricatesoftware.com>

It is convenient to be able to set DEFAULT_LIBPATH
during build time. The other half of this is already
included in src/os/bsd/vm/os_bsd.cpp.

diff -r 36e8a25a0058 make/bsd/makefiles/vm.make
--- a/make/bsd/makefiles/vm.make	Wed Jan 14 11:53:48 2009 -0500
+++ b/make/bsd/makefiles/vm.make	Wed Jan 14 13:35:25 2009 -0500
@@ -86,6 +86,10 @@
   ${JRE_VERSION}     \
   ${VM_DISTRO}
 
+ifdef DEFAULT_LIBPATH
+CPPFLAGS += -DDEFAULT_LIBPATH="\"$(DEFAULT_LIBPATH)\""
+endif
+
 # CFLAGS_WARN holds compiler options to suppress/enable warnings.
 CFLAGS += $(CFLAGS_WARN/BYFILE)
 



From kurt at intricatesoftware.com  Wed Jan 14 13:55:30 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Wed, 14 Jan 2009 21:55:30 +0000
Subject: hg: bsd-port/bsd-port/jdk: 2 new changesets
Message-ID: <20090114215555.6ABBAD68E@hg.openjdk.java.net>

Changeset: a82e8567ebc4
Author:    kurt
Date:      2009-01-14 16:50 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/a82e8567ebc4

Summary: Remove incorrect prep-target copied from windows build
Reviewed by: Xiaobin

prep-target requires a file based target. When used with a
directory based target it causes build failures on OS X.

! make/java/jli/Makefile

Changeset: 859cd8d197a6
Author:    kurt
Date:      2009-01-14 16:52 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/859cd8d197a6

Summary: Path corrections (utils & cups)
Reviewed by: glewis, xiaobin

- Set DEVTOOLS_PATH to $(PACKAGE_PATH)/bin/ which is the correct
  location for tools that don't come preinstalled with the platform.
- Set _CUPS_HEADERS_PATH correctly for Apple which comes
  with cups.
- Set up full paths to utils defined in Defs-utils.gmk
  for bsd with exceptions for OS_VENDOR differences.

! make/common/shared/Defs-bsd.gmk
! make/common/shared/Defs-utils.gmk



From kurt at intricatesoftware.com  Wed Jan 14 14:00:31 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Wed, 14 Jan 2009 22:00:31 +0000
Subject: hg: bsd-port/bsd-port/corba: Summary: Path corrections (utils & misc
	others)
Message-ID: <20090114220032.AFB0DD695@hg.openjdk.java.net>

Changeset: 10646cc7348c
Author:    kurt
Date:      2009-01-14 16:58 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/corba/rev/10646cc7348c

Summary: Path corrections (utils & misc others)
Reviewed By: glewis, xiaobin

- Sync Defs.gmk with jdk version by defining PACKAGE_PATH and moving
  the X11_PATH definition to before including platform definitions.
- Set DEVTOOLS_PATH to $(PACKAGE_PATH)/bin/ which is the correct
  location for tools that don't come preinstalled with the platform.
- Sync USRJDKINSTANCES_PATH to match the corresponding jdk value.
- Set up full paths to utils defined in Defs-utils.gmk
  for bsd with exceptions for OS_VENDOR differences.

! make/common/Defs.gmk
! make/common/shared/Defs-bsd.gmk
! make/common/shared/Defs-utils.gmk



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 mvfranz at gmail.com  Thu Jan 15 19:54:09 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Thu, 15 Jan 2009 22:54:09 -0500
Subject: Apple Specific fontconfig
Message-ID: <fee4d890901151954l230047bdq62b0727b176b2090@mail.gmail.com>

I compiled the JDK without the following logic (I did not use the Apple
specific logic).  Is that enough to verify that there is no need for the
Apple logic anymore?  I was also able to run a sample 'Notepad' Java
application.

#ifdef __APPLE__
// XXXDARWIN: Hard-code the path to Apple's freetype, as it is
// not included in the dyld search path by default, and 10.4
// does not support -rpath.
//
// This ignores the build time setting of ALT_FREETYPE_LIB_PATH,
// and should be replaced with -rpath/@rpath support on 10.5 or later,
// or via support for a the FREETYPE_LIB_PATH define.
#define FONTCONFIG_DLL_VERSIONED X11_PATH "/lib/"
VERSIONED_JNI_LIB_NAME("fontconfig", "1")
#define FONTCONFIG_DLL X11_PATH "/lib/" JNI_LIB_NAME("fontconfig")
#else
#define FONTCONFIG_DLL_VERSIONED VERSIONED_JNI_LIB_NAME("fontconfig", "1")
#define FONTCONFIG_DLL JNI_LIB_NAME("fontconfig")
#endif

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090115/62f9aeb0/attachment.html 

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 kurt at intricatesoftware.com  Fri Jan 16 08:25:55 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Fri, 16 Jan 2009 16:25:55 +0000
Subject: hg: bsd-port/bsd-port/jdk: Use FAIL_FILENO + 1 for OpenBSD's
	closeDescriptors
Message-ID: <20090116162606.DE644DAD4@hg.openjdk.java.net>

Changeset: fc30e7f4b9b3
Author:    kurt
Date:      2009-01-16 11:24 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/fc30e7f4b9b3

Use FAIL_FILENO + 1 for OpenBSD's closeDescriptors
instead of hard coding it which matches the !OpenBSD
from_fd.

! src/solaris/native/java/lang/UNIXProcess_md.c



From kurt at intricatesoftware.com  Fri Jan 16 10:23:15 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Fri, 16 Jan 2009 18:23:15 +0000
Subject: hg: bsd-port/bsd-port/hotspot: Fix the datatype of argv in
	fork_and_exec() and cast it for execve(2).
Message-ID: <20090116182317.A99ECDADB@hg.openjdk.java.net>

Changeset: f337b3e25cbf
Author:    kurt
Date:      2009-01-16 13:21 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/f337b3e25cbf

Fix the datatype of argv in fork_and_exec() and cast it for execve(2).
Eliminates a gcc 4.2.1 warning on FreeBSD 7.

! src/os/bsd/vm/os_bsd.cpp



From kurt at intricatesoftware.com  Fri Jan 16 10:30:26 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Fri, 16 Jan 2009 18:30:26 +0000
Subject: hg: bsd-port/bsd-port/hotspot: Enable WARNINGS_ARE_ERRORS for bsd. We
	want a warning free hotspot
Message-ID: <20090116183028.CE43ADAE0@hg.openjdk.java.net>

Changeset: 6e1e3c98ccdf
Author:    kurt
Date:      2009-01-16 13:29 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/6e1e3c98ccdf

Enable WARNINGS_ARE_ERRORS for bsd. We want a warning free hotspot
build the same as linux and solaris have.

! make/bsd/makefiles/gcc.make



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 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 glewis at eyesbeyond.com  Fri Jan 16 23:24:54 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Sat, 17 Jan 2009 07:24:54 +0000
Subject: hg: bsd-port/bsd-port/hotspot: 3 new changesets
Message-ID: <20090117072500.C66BBDB64@hg.openjdk.java.net>

Changeset: dabd8d202164
Author:    coleenp
Date:      2008-12-23 06:16 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/dabd8d202164

4997835: RFE: crash dump will only be created when running w/ -XX:+ShowMessageBoxOnError
Summary: Using UseOSErrorReporting will provide both an hs_err file and a crash dump or debug launch and works better.
Reviewed-by: xlu, acorn, poonam

! src/share/vm/utilities/vmError.cpp

Changeset: db4caa99ef11
Author:    xlu
Date:      2008-12-24 13:06 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/db4caa99ef11

6787106: Hotspot 32 bit build fails on platforms having different definitions for intptr_t & int32_t
Summary: Avoid casting between int32_t and intptr_t specifically for MasmAssembler::movptr in 32 bit platforms.
Reviewed-by: jrose, kvn

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_32.hpp
! src/cpu/x86/vm/interpreterRT_x86_32.cpp
! src/cpu/x86/vm/runtime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/x86_32.ad
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp

Changeset: a87e8ceb2b1f
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-16 21:34 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/a87e8ceb2b1f

. Merge changes from the main HotSpot repository inclusive of
  Xiaobin Lu's fixes that allow Mac OS X and OpenBSD to build.

! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/share/vm/utilities/globalDefinitions_gcc.hpp
! src/share/vm/utilities/vmError.cpp



From glewis at eyesbeyond.com  Fri Jan 16 23:34:20 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Fri, 16 Jan 2009 23:34:20 -0800
Subject: hg: bsd-port/bsd-port/hotspot: 3 new changesets
In-Reply-To: <20090117072500.C66BBDB64@hg.openjdk.java.net>
References: <20090117072500.C66BBDB64@hg.openjdk.java.net>
Message-ID: <20090117073420.GA97806@misty.eyesbeyond.com>

On Sat, Jan 17, 2009 at 07:24:54AM +0000, glewis at eyesbeyond.com wrote:
...

Hopefully this fixes the build for Mac OS X and OpenBSD and won't cause us
any merge issues later on :).

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From mvfranz at gmail.com  Sat Jan 17 05:39:12 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sat, 17 Jan 2009 08:39:12 -0500
Subject: hg: bsd-port/bsd-port/hotspot: 3 new changesets
In-Reply-To: <20090117073420.GA97806@misty.eyesbeyond.com>
References: <20090117072500.C66BBDB64@hg.openjdk.java.net>
	<20090117073420.GA97806@misty.eyesbeyond.com>
Message-ID: <fee4d890901170539t696587edm77de8d5b3450e1c8@mail.gmail.com>

Let me try now!

On Sat, Jan 17, 2009 at 2:34 AM, Greg Lewis <glewis at eyesbeyond.com> wrote:

> On Sat, Jan 17, 2009 at 07:24:54AM +0000, glewis at eyesbeyond.com wrote:
> ...
>
> Hopefully this fixes the build for Mac OS X and OpenBSD and won't cause us
> any merge issues later on :).
>
> --
> Greg Lewis                          Email   : glewis at eyesbeyond.com
> Eyes Beyond                         Web     : http://www.eyesbeyond.com
> Information Technology              FreeBSD : glewis at FreeBSD.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090117/d74c63ea/attachment.html 

From pierre.queinnec at zenika.com  Sat Jan 17 06:01:44 2009
From: pierre.queinnec at zenika.com (Pierre Queinnec)
Date: Sat, 17 Jan 2009 15:01:44 +0100
Subject: hg: bsd-port/bsd-port/hotspot: 3 new changesets
In-Reply-To: <fee4d890901170539t696587edm77de8d5b3450e1c8@mail.gmail.com>
References: <20090117072500.C66BBDB64@hg.openjdk.java.net>	<20090117073420.GA97806@misty.eyesbeyond.com>
	<fee4d890901170539t696587edm77de8d5b3450e1c8@mail.gmail.com>
Message-ID: <4971E4C8.70209@zenika.com>

It still doesn't build for me (trying to build 32bit, using Landon's 
SoyLatte-1.0.3 to bootstrap).

$ uname -a
Darwin pasiphae 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 
PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386

$ xcodebuild -version
Xcode 3.1.1
Component versions: DevToolsCore-1114.0; DevToolsSupport-1102.0
BuildVersion: 9M2517

$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5488~2/src/configure 
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ 
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib 
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic 
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5488)

I had to use a slightly modified version of Michael Franz's patch 
(attached) to make it build. Sorry if I'm overlooking something.

Regards,
-- 
Pierre Queinnec
Architecte - Zenika
http://www.zenika.com



Michael Franz wrote:
> Let me try now!
> 
> On Sat, Jan 17, 2009 at 2:34 AM, Greg Lewis <glewis at eyesbeyond.com 
> <mailto:glewis at eyesbeyond.com>> wrote:
> 
>     On Sat, Jan 17, 2009 at 07:24:54AM +0000, glewis at eyesbeyond.com
>     <mailto:glewis at eyesbeyond.com> wrote:
>     ...
> 
>     Hopefully this fixes the build for Mac OS X and OpenBSD and won't
>     cause us
>     any merge issues later on :).
> 
>     --
>     Greg Lewis                          Email   : glewis at eyesbeyond.com
>     <mailto:glewis at eyesbeyond.com>
>     Eyes Beyond                         Web     : http://www.eyesbeyond.com
>     Information Technology              FreeBSD : glewis at FreeBSD.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hotspot-32bit.diff.gz
Type: application/x-gzip
Size: 1301 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090117/fcd8c127/hotspot-32bit.diff.gz 

From Weijun.Wang at Sun.COM  Sat Jan 17 06:35:15 2009
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Sat, 17 Jan 2009 22:35:15 +0800
Subject: A patch for src/solaris/classes/sun/awt/X11/XKeysym.java
Message-ID: <9BF2F932-6819-4EA2-922C-7194A8F2FFD9@sun.com>

Hi, BSD Hackers

I'm using the bsd-port openjdk to run NetBeans on my MacBook. There's  
a problem that when you press Command+X in the editor, besides the  
keyboard shortcut being executed, the letter "X" itself goes into the  
edited file.

I've coined the following patch and at least NetBeans works fine now.

diff --git a/src/solaris/classes/sun/awt/X11/XKeysym.java b/src/ 
solaris/classes/sun/awt/X11/XKeysym.java
--- a/src/solaris/classes/sun/awt/X11/XKeysym.java
+++ b/src/solaris/classes/sun/awt/X11/XKeysym.java
@@ -70,7 +70,7 @@
          /* First check for Latin-1 characters (1:1 mapping) */
          if ((ks >= 0x0020 && ks <= 0x007e) ||
              (ks >= 0x00a0 && ks <= 0x00ff)) {
-            if( (state & XConstants.ControlMask) != 0 ) {
+            if( (state & XConstants.ControlMask) != 0 || (state &  
16) != 0 ) {
                  if ((ks >= 'A' && ks <= ']') || (ks == '_') ||
                      (ks >= 'a' && ks <='z')) {
                      ks &= 0x1F;

I'm neither a BSD nor an X11/awt expert, so I'm completely not sure if  
this really fixes the problem or has broken other things.

Thanks
Max



From mvfranz at gmail.com  Sat Jan 17 08:09:07 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Sat, 17 Jan 2009 11:09:07 -0500
Subject: hg: bsd-port/bsd-port/hotspot: 3 new changesets
In-Reply-To: <4971E4C8.70209@zenika.com>
References: <20090117072500.C66BBDB64@hg.openjdk.java.net>
	<20090117073420.GA97806@misty.eyesbeyond.com>
	<fee4d890901170539t696587edm77de8d5b3450e1c8@mail.gmail.com>
	<4971E4C8.70209@zenika.com>
Message-ID: <fee4d890901170809n297c0353r5287a3dd79f853c2@mail.gmail.com>

I have the same issues.  Guess we will have to wait for more patches. :(


On Sat, Jan 17, 2009 at 9:01 AM, Pierre Queinnec <pierre.queinnec at zenika.com
> wrote:

> It still doesn't build for me (trying to build 32bit, using Landon's
> SoyLatte-1.0.3 to bootstrap).
>
> $ uname -a
> Darwin pasiphae 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST
> 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386
>
> $ xcodebuild -version
> Xcode 3.1.1
> Component versions: DevToolsCore-1114.0; DevToolsSupport-1102.0
> BuildVersion: 9M2517
>
> $ gcc -v
> Using built-in specs.
> Target: i686-apple-darwin9
> Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking
> -enable-werror --prefix=/usr --mandir=/share/man
> --enable-languages=c,objc,c++,obj-c++
> --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
> --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
> --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
> --host=i686-apple-darwin9 --target=i686-apple-darwin9
> Thread model: posix
> gcc version 4.0.1 (Apple Inc. build 5488)
>
> I had to use a slightly modified version of Michael Franz's patch
> (attached) to make it build. Sorry if I'm overlooking something.
>
> Regards,
> --
> Pierre Queinnec
> Architecte - Zenika
> http://www.zenika.com
>
>
>
> Michael Franz wrote:
>
>> Let me try now!
>>
>> On Sat, Jan 17, 2009 at 2:34 AM, Greg Lewis <glewis at eyesbeyond.com<mailto:
>> glewis at eyesbeyond.com>> wrote:
>>
>>    On Sat, Jan 17, 2009 at 07:24:54AM +0000, glewis at eyesbeyond.com
>>    <mailto:glewis at eyesbeyond.com> wrote:
>>    ...
>>
>>    Hopefully this fixes the build for Mac OS X and OpenBSD and won't
>>    cause us
>>    any merge issues later on :).
>>
>>    --
>>    Greg Lewis                          Email   : glewis at eyesbeyond.com
>>    <mailto:glewis at eyesbeyond.com>
>>    Eyes Beyond                         Web     :
>> http://www.eyesbeyond.com
>>    Information Technology              FreeBSD : glewis at FreeBSD.org
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090117/c677f684/attachment.html 

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/bsd-port-dev/attachments/20090118/9d3e7f18/attachment.html 

From glewis at eyesbeyond.com  Sun Jan 18 21:43:38 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Mon, 19 Jan 2009 05:43:38 +0000
Subject: hg: bsd-port/bsd-port/hotspot: . Add,
	remove and alter casts to get this to compile on Mac OS X (in 32 bit
Message-ID: <20090119054340.9623EDBC3@hg.openjdk.java.net>

Changeset: b86ce5362022
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-18 21:42 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/b86ce5362022

. Add, remove and alter casts to get this to compile on Mac OS X (in 32 bit
  mode at least).

! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interpreterRT_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp



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 mvfranz at gmail.com  Mon Jan 19 05:58:22 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Mon, 19 Jan 2009 08:58:22 -0500
Subject: hg: bsd-port/bsd-port/hotspot: . Add, remove and alter casts to 
	get this to compile on Mac OS X (in 32 bit
In-Reply-To: <20090119054340.9623EDBC3@hg.openjdk.java.net>
References: <20090119054340.9623EDBC3@hg.openjdk.java.net>
Message-ID: <fee4d890901190558w25cfd1cdn92a77741c4eb482a@mail.gmail.com>

Greg,

Thanks for committing these changes, are they from upstream?  One question I
have, what is the purpose of NULL_WORD?  Should NULL_WORD be used in this
patch instead of casting NULL to intptr_t?

--- a/src/cpu/x86/vm/interpreterRT_x86_32.cpp	Fri Jan 16 21:34:21 2009 -0800
+++ b/src/cpu/x86/vm/interpreterRT_x86_32.cpp	Sun Jan 18 21:42:26 2009 -0800
@@ -110,7 +110,7 @@ class SlowSignatureHandler: public Nativ
   virtual void pass_object() {
     // pass address of from
     intptr_t from_addr = (intptr_t)(_from +
Interpreter::local_offset_in_bytes(0));
-    *_to++ = (*(intptr_t*)from_addr == 0) ? NULL : from_addr;
+    *_to++ = (*(intptr_t*)from_addr == 0) ? (intptr_t) NULL : from_addr;
     debug_only(verify_tag(frame::TagReference));
     _from -= Interpreter::stackElementSize();
    }


Michael

On Mon, Jan 19, 2009 at 12:43 AM, <glewis at eyesbeyond.com> wrote:

> Changeset: b86ce5362022
> Author:    glewis at misty.eyesbeyond.com
> Date:      2009-01-18 21:42 -0800
> URL:
> http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/b86ce5362022
>
> . Add, remove and alter casts to get this to compile on Mac OS X (in 32 bit
>  mode at least).
>
> ! src/cpu/x86/vm/c1_Runtime1_x86.cpp
> ! src/cpu/x86/vm/interp_masm_x86_32.cpp
> ! src/cpu/x86/vm/interpreterRT_x86_32.cpp
> ! src/cpu/x86/vm/stubGenerator_x86_32.cpp
> ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
> ! src/cpu/x86/vm/templateTable_x86_32.cpp
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090119/59441692/attachment.html 

From zondolfin at gmail.com  Sun Jan 18 15:45:46 2009
From: zondolfin at gmail.com (Martin Kihlgren)
Date: Mon, 19 Jan 2009 00:45:46 +0100
Subject: java.nio and SelectionKey.interestOps(int i)
Message-ID: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>

Hello list!

I have this problem that I thought maybe you could help explaining.

I have this application, where a server thread loops around a
select(), and then does stuff to the different SelectableChannels that
pops out from the Selector.

If something is read from a channel, for example, I send it to a
handler. And if the handler wants to respond in some way, it adds it
to a queue and then does interestOps(interestOps() &
SelectionKey.OP_WRITE) on its SelectionKey. Then it does wakeup() on
its Selector.

In Sun's java 6 for linux, this works beautifully. The Selector wakes
up, does another select, and finds that suddenly this
SelectableChannel wants to be (and can be) written to.

In SoyLatte, however, nothing happens! No matter if I wake the
selector up one or many times, it doesn't recognize that the
SelectableChannel and its SelectionKey is interested in OP_WRITE.

Any ideas?

regards,
//Martin Kihlgren


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 glewis at eyesbeyond.com  Mon Jan 19 09:40:56 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Mon, 19 Jan 2009 09:40:56 -0800
Subject: hg: bsd-port/bsd-port/hotspot: . Add, remove and alter casts
	to get this to compile on Mac OS X (in 32 bit
In-Reply-To: <fee4d890901190558w25cfd1cdn92a77741c4eb482a@mail.gmail.com>
References: <20090119054340.9623EDBC3@hg.openjdk.java.net>
	<fee4d890901190558w25cfd1cdn92a77741c4eb482a@mail.gmail.com>
Message-ID: <20090119174056.GA91077@misty.eyesbeyond.com>

G'day Michael,

On Mon, Jan 19, 2009 at 08:58:22AM -0500, Michael Franz wrote:
> Thanks for committing these changes, are they from upstream?

Unfortunately not.  They are just what I needed to get things built now
that I finally have my tools updated and can build on Mac OS X.  I think
its worth asking Xiaobin if he would be interested in pushing them
upstream though to reduce future merge conflicts.

> One question I have, what is the purpose of NULL_WORD?  Should NULL_WORD
> be used in this patch instead of casting NULL to intptr_t?

Thats a reasonable question.  I think the change below was a result of
Kurt turning -Werror on (which is a good thing).  The original code
generated a warning which I've just cast away for now.  I don't have
an answer for you off the top of my head :).

> --- a/src/cpu/x86/vm/interpreterRT_x86_32.cpp	Fri Jan 16 21:34:21 2009 -0800
> +++ b/src/cpu/x86/vm/interpreterRT_x86_32.cpp	Sun Jan 18 21:42:26 2009 -0800
> @@ -110,7 +110,7 @@ class SlowSignatureHandler: public Nativ
>    virtual void pass_object() {
>      // pass address of from
>      intptr_t from_addr = (intptr_t)(_from +
> Interpreter::local_offset_in_bytes(0));
> -    *_to++ = (*(intptr_t*)from_addr == 0) ? NULL : from_addr;
> +    *_to++ = (*(intptr_t*)from_addr == 0) ? (intptr_t) NULL : from_addr;
>      debug_only(verify_tag(frame::TagReference));
>      _from -= Interpreter::stackElementSize();
>     }
> 
> 
> Michael
> 
> On Mon, Jan 19, 2009 at 12:43 AM, <glewis at eyesbeyond.com> wrote:
> 
> > Changeset: b86ce5362022
> > Author:    glewis at misty.eyesbeyond.com
> > Date:      2009-01-18 21:42 -0800
> > URL:
> > http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/b86ce5362022
> >
> > . Add, remove and alter casts to get this to compile on Mac OS X (in 32 bit
> >  mode at least).
> >
> > ! src/cpu/x86/vm/c1_Runtime1_x86.cpp
> > ! src/cpu/x86/vm/interp_masm_x86_32.cpp
> > ! src/cpu/x86/vm/interpreterRT_x86_32.cpp
> > ! src/cpu/x86/vm/stubGenerator_x86_32.cpp
> > ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
> > ! src/cpu/x86/vm/templateTable_x86_32.cpp
> >
> >
> >

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From mvfranz at gmail.com  Mon Jan 19 10:54:50 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Mon, 19 Jan 2009 13:54:50 -0500
Subject: Pulling from OpenJDK7 - Confused on BinaryPlugs.gmk
Message-ID: <fee4d890901191054t2cd4bae2n2a752cf906700a65@mail.gmail.com>

Hi,

I tried to pull from OpenJDK7 hg pull
http://hg.openjdk.java.net/jdk7/jdk7into a local bsd repo.  There was
only 1 conflict (not my issue) but I did
not get the changes I was expecting.  I am trying to get my version of
jdk/make/common/internal/BinaryPlugs.gmk to be the same as the version in
JDK7.  Since I am not a very good with mercurial I am not sure what I need
to do to get the the version from JDK7 into my local version.

I guess, I don't understand why I am not getting the latest version.

Thanks

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090119/36ae43e1/attachment.html 

From glewis at eyesbeyond.com  Mon Jan 19 13:31:39 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Mon, 19 Jan 2009 13:31:39 -0800
Subject: Pulling from OpenJDK7 - Confused on BinaryPlugs.gmk
In-Reply-To: <fee4d890901191054t2cd4bae2n2a752cf906700a65@mail.gmail.com>
References: <fee4d890901191054t2cd4bae2n2a752cf906700a65@mail.gmail.com>
Message-ID: <20090119213139.GA94799@misty.eyesbeyond.com>

G'day Michael,

On Mon, Jan 19, 2009 at 01:54:50PM -0500, Michael Franz wrote:
> I tried to pull from OpenJDK7 hg pull
> http://hg.openjdk.java.net/jdk7/jdk7into a local bsd repo.  There was
> only 1 conflict (not my issue) but I did
> not get the changes I was expecting.  I am trying to get my version of
> jdk/make/common/internal/BinaryPlugs.gmk to be the same as the version in
> JDK7.  Since I am not a very good with mercurial I am not sure what I need
> to do to get the the version from JDK7 into my local version.
> 
> I guess, I don't understand why I am not getting the latest version.

Did you run an update after you did the pull?  I don't believe it merges
in the changes until you do that.

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From mvfranz at gmail.com  Mon Jan 19 15:14:49 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Mon, 19 Jan 2009 18:14:49 -0500
Subject: Pulling from OpenJDK7 - Confused on BinaryPlugs.gmk
In-Reply-To: <20090119213139.GA94799@misty.eyesbeyond.com>
References: <fee4d890901191054t2cd4bae2n2a752cf906700a65@mail.gmail.com>
	<20090119213139.GA94799@misty.eyesbeyond.com>
Message-ID: <fee4d890901191514v52c619ebl56b619b64b499c58@mail.gmail.com>

hg update -C did the trick.

thanks

On Mon, Jan 19, 2009 at 4:31 PM, Greg Lewis <glewis at eyesbeyond.com> wrote:

> G'day Michael,
>
> On Mon, Jan 19, 2009 at 01:54:50PM -0500, Michael Franz wrote:
> > I tried to pull from OpenJDK7 hg pull
> > http://hg.openjdk.java.net/jdk7/jdk7into a local bsd repo.  There was
> > only 1 conflict (not my issue) but I did
> > not get the changes I was expecting.  I am trying to get my version of
> > jdk/make/common/internal/BinaryPlugs.gmk to be the same as the version in
> > JDK7.  Since I am not a very good with mercurial I am not sure what I
> need
> > to do to get the the version from JDK7 into my local version.
> >
> > I guess, I don't understand why I am not getting the latest version.
>
> Did you run an update after you did the pull?  I don't believe it merges
> in the changes until you do that.
>
> --
> Greg Lewis                          Email   : glewis at eyesbeyond.com
> Eyes Beyond                         Web     : http://www.eyesbeyond.com
> Information Technology              FreeBSD : glewis at FreeBSD.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090119/ba9d8b7f/attachment.html 

From gbenson at redhat.com  Tue Jan 20 02:57:27 2009
From: gbenson at redhat.com (Gary Benson)
Date: Tue, 20 Jan 2009 10:57:27 +0000
Subject: IcedTea Bootstrap Process
In-Reply-To: <20090119171512.GA90423@misty.eyesbeyond.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>
	<20090119171512.GA90423@misty.eyesbeyond.com>
Message-ID: <20090120105727.GC3208@redhat.com>

Greg Lewis wrote:
> 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.

That's pretty much how it is for Zero too.

> 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?

Some shared code?  Zero is *all* shared code :D There is a bit in
os_linux_zero.cpp [1] to handle ia64's wacky stack, a bit in
os_linux_zero.hpp [2] to provide 64-bit atomic copy on 32-bit pcc,
and some bits in atomic_linux_zero.inline.hpp [3] to provide atomic
operations on m68k and arm, but the remaining 6000 lines or so are
plain old C++, with the odd conditional here and there to cope with
differences in endianness and word size.

Zero is basically a CPU port; to the makefiles, when you build with
Zero your $ARCH is "zero" rather than "x86" or "sparc" or whatever.
If you check out a copy of IcedTea (6 or 7) you'll see a ports
directory, the contents of which are symlinked into the OpenJDK tree
at the start of the build.  Aside from a couple of patches, the vast
majority of zero is here:

  ports/hotspot/src/cpu/zero
  ports/hotspot/src/os_cpu/linux_zero

To port Zero to BSD, what you basically need to create is this:

  ports/hotspot/src/os_cpu/bsd_zero

There's something like 1300 lines of code in there, but pretty much
all of it can just be copied straight from the Linux directory.
You could get a nice starting point with something like:

  for i in ports/hotspot/src/os_cpu/linux_zero/vm/*; do
      j=`echo $i | sed 's/linux_zero/bsd_zero/'`
      sed 's/linux_zero\.cpp/bsd_zero.cpp/' < $i > $j
  done

os_linux_zero.cpp may need a little more work but hopefully not much.

> Also, what progress has been made getting Zero into the main
> OpenJDK7 sources (which is an approved project as I understand it)?

It's an approved project, but I haven't started using its repo yet.
There are two reasons why.  One is that there are a bunch of cpu-
specific patches in IcedTea that Zero needs, and I need to take a
week to sit down, check they're necessary, file bugs, and submit
patches and make testcases for them all.  (This is a lot easier
now that IcedTea6 is using the latest HotSpot.)  The other reason
is that Zero is a bit too slow for me to want to develop it without
the ecj-bootstrap stuff in IcedTea; once Shark is good enough to
develop with (and it so very nearly is) I'll get to switching over.
It's taken much longer than I anticipated because I've taken some
time out of Shark development to work on getting a Zero build to
pass the TCK.

Cheers,
Gary

--
http://gbenson.net/

[1] http://tinyurl.com/os-linux-zero-cpp, from line 307
[2] http://tinyurl.com/os-linux-zero-hpp, from line 37
[3] http://tinyurl.com/atomic-linux-zero-inline-hpp, from lines 28 and 103


From David.Herron at Sun.COM  Tue Jan 20 07:54:58 2009
From: David.Herron at Sun.COM (David Herron @ Sun)
Date: Tue, 20 Jan 2009 07:54:58 -0800
Subject: IcedTea Bootstrap Process
In-Reply-To: <20090117044737.BD0F0D068@callebaut.niobe.net>
References: <20090117044737.BD0F0D068@callebaut.niobe.net>
Message-ID: <4975F3D2.5010509@sun.com>

Mark Reinhold wrote:
>> 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
>
>   
And (stating a somewhat obvious point) for 'maintained by someone' to 
include QA and bug triage/fixing.

It may be worthwhile to have a proper statement somewhere on 
openjdk.java.net regarding the process of ownership and maintenance of 
different subsections of the main tree.

- David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090120/cb95671a/attachment.html 

From kurt at intricatesoftware.com  Tue Jan 20 07:57:08 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Tue, 20 Jan 2009 10:57:08 -0500
Subject: hg: bsd-port/bsd-port/hotspot: . Add, remove and alter casts
	to get this to compile on Mac OS X (in 32 bit
In-Reply-To: <20090119174056.GA91077@misty.eyesbeyond.com>
References: <20090119054340.9623EDBC3@hg.openjdk.java.net>	<fee4d890901190558w25cfd1cdn92a77741c4eb482a@mail.gmail.com>
	<20090119174056.GA91077@misty.eyesbeyond.com>
Message-ID: <4975F454.7000102@intricatesoftware.com>

Greg Lewis wrote:
> G'day Michael,
> 
> On Mon, Jan 19, 2009 at 08:58:22AM -0500, Michael Franz wrote:
>> Thanks for committing these changes, are they from upstream?
> 
> Unfortunately not.  They are just what I needed to get things built now
> that I finally have my tools updated and can build on Mac OS X.  I think
> its worth asking Xiaobin if he would be interested in pushing them
> upstream though to reduce future merge conflicts.
> 
>> One question I have, what is the purpose of NULL_WORD?  Should NULL_WORD
>> be used in this patch instead of casting NULL to intptr_t?
> 
> Thats a reasonable question.  I think the change below was a result of
> Kurt turning -Werror on (which is a good thing).  The original code
> generated a warning which I've just cast away for now.  I don't have
> an answer for you off the top of my head :).

Yes NULL_WORD is the correct value to use here. The result is going
into a intptr_t so we want (intptr_t)0 to be used.

I have more datatype changes to add including this one. I will post
them under a new thread.

> 
>> --- a/src/cpu/x86/vm/interpreterRT_x86_32.cpp	Fri Jan 16 21:34:21 2009 -0800
>> +++ b/src/cpu/x86/vm/interpreterRT_x86_32.cpp	Sun Jan 18 21:42:26 2009 -0800
>> @@ -110,7 +110,7 @@ class SlowSignatureHandler: public Nativ
>>    virtual void pass_object() {
>>      // pass address of from
>>      intptr_t from_addr = (intptr_t)(_from +
>> Interpreter::local_offset_in_bytes(0));
>> -    *_to++ = (*(intptr_t*)from_addr == 0) ? NULL : from_addr;
>> +    *_to++ = (*(intptr_t*)from_addr == 0) ? (intptr_t) NULL : from_addr;
>>      debug_only(verify_tag(frame::TagReference));
>>      _from -= Interpreter::stackElementSize();
>>     }
>>
>>
>> Michael
>>
>> On Mon, Jan 19, 2009 at 12:43 AM, <glewis at eyesbeyond.com> wrote:
>>
>>> Changeset: b86ce5362022
>>> Author:    glewis at misty.eyesbeyond.com
>>> Date:      2009-01-18 21:42 -0800
>>> URL:
>>> http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/b86ce5362022
>>>
>>> . Add, remove and alter casts to get this to compile on Mac OS X (in 32 bit
>>>  mode at least).
>>>
>>> ! src/cpu/x86/vm/c1_Runtime1_x86.cpp
>>> ! src/cpu/x86/vm/interp_masm_x86_32.cpp
>>> ! src/cpu/x86/vm/interpreterRT_x86_32.cpp
>>> ! src/cpu/x86/vm/stubGenerator_x86_32.cpp
>>> ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
>>> ! src/cpu/x86/vm/templateTable_x86_32.cpp
>>>
>>>
>>>
> 



From kurt at intricatesoftware.com  Tue Jan 20 08:20:58 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Tue, 20 Jan 2009 11:20:58 -0500
Subject: Additional type corrections
Message-ID: <200901201120.59423.kurt@intricatesoftware.com>

Here are more datatype corrections for the bsd-port tree. I've
tested a variation of this diff on my OpenBSD port (the bsd-port
tree doesn't build yet on OpenBSD; still a work in progress). These
should be committed and then we need to extract all the datatype
corrections for submitting a new bug report for the main tree.

The changes are as follows:
- There is no movptr(Address, int32_t) function for x86/32 bit.
Casting to int32_t for movptr on x86/32 should be avoided. Instead
cast directly to intptr_t where needed.
- Several places in the x86/32 code movl is directly used where
movptr is the correct function. movptr on x86/32 ends up using
movl but deals with the type variations without the need for
additional casts.
- Use NULL_WORD to assign a NULL value to intptr_t instead of
(intptr_t) NULL

diff -r b86ce5362022 src/cpu/x86/vm/interp_masm_x86_32.cpp
--- a/src/cpu/x86/vm/interp_masm_x86_32.cpp	Sun Jan 18 21:42:26 2009 -0800
+++ b/src/cpu/x86/vm/interp_masm_x86_32.cpp	Tue Jan 20 10:49:33 2009 -0500
@@ -149,7 +149,7 @@
   // Clean up tos value in the thread object
   movl(tos_addr,  (int32_t) ilgl);
   movptr(val_addr,  NULL_WORD);
-  NOT_LP64(movl(val_addr1, (int32_t)NULL_WORD));
+  NOT_LP64(movptr(val_addr1, NULL_WORD));
 }
 
 
@@ -473,7 +473,7 @@
       movptr(Address(rdi, Interpreter::local_tag_offset_in_bytes(n+1)), (intptr_t)frame::TagValue);
       movptr(Address(rdi, Interpreter::local_tag_offset_in_bytes(n)), (intptr_t)frame::TagValue);
     } else {
-      movptr(Address(rdi, Interpreter::local_tag_offset_in_bytes(n)), (int32_t)tag);
+      movptr(Address(rdi, Interpreter::local_tag_offset_in_bytes(n)), (intptr_t)tag);
     }
   }
 }
@@ -487,7 +487,7 @@
                     Interpreter::local_tag_offset_in_bytes(0)), (intptr_t)frame::TagValue);
     } else {
       movptr(Address(rdi, idx, Interpreter::stackElementScale(),
-                               Interpreter::local_tag_offset_in_bytes(0)), (int32_t)tag);
+                               Interpreter::local_tag_offset_in_bytes(0)), (intptr_t)tag);
     }
   }
 }
@@ -1319,7 +1319,7 @@
   int recvr_offset = in_bytes(VirtualCallData::receiver_offset(start_row));
   set_mdp_data_at(mdp, recvr_offset, receiver);
   int count_offset = in_bytes(VirtualCallData::receiver_count_offset(start_row));
-  movptr(reg2, (int32_t)DataLayout::counter_increment);
+  movptr(reg2, (intptr_t)DataLayout::counter_increment);
   set_mdp_data_at(mdp, count_offset, reg2);
   jmp(done);
 }
@@ -1458,7 +1458,7 @@
     test_method_data_pointer(mdp, profile_continue);
 
     // Build the base (index * per_case_size_in_bytes()) + case_array_offset_in_bytes()
-    movptr(reg2, (int32_t)in_bytes(MultiBranchData::per_case_size()));
+    movptr(reg2, (intptr_t)in_bytes(MultiBranchData::per_case_size()));
     // index is positive and so should have correct value if this code were
     // used on 64bits
     imulptr(index, reg2);
diff -r b86ce5362022 src/cpu/x86/vm/interpreterRT_x86_32.cpp
--- a/src/cpu/x86/vm/interpreterRT_x86_32.cpp	Sun Jan 18 21:42:26 2009 -0800
+++ b/src/cpu/x86/vm/interpreterRT_x86_32.cpp	Tue Jan 20 10:49:33 2009 -0500
@@ -110,7 +110,7 @@
   virtual void pass_object() {
     // pass address of from
     intptr_t from_addr = (intptr_t)(_from + Interpreter::local_offset_in_bytes(0));
-    *_to++ = (*(intptr_t*)from_addr == 0) ? (intptr_t) NULL : from_addr;
+    *_to++ = (*(intptr_t*)from_addr == 0) ? NULL_WORD : from_addr;
     debug_only(verify_tag(frame::TagReference));
     _from -= Interpreter::stackElementSize();
    }
diff -r b86ce5362022 src/cpu/x86/vm/templateTable_x86_32.cpp
--- a/src/cpu/x86/vm/templateTable_x86_32.cpp	Sun Jan 18 21:42:26 2009 -0800
+++ b/src/cpu/x86/vm/templateTable_x86_32.cpp	Tue Jan 20 10:49:33 2009 -0500
@@ -137,10 +137,10 @@
         // Do the actual store
         // noreg means NULL
         if (val == noreg) {
-          __ movl(Address(rdx, 0), (int32_t)NULL_WORD);
+          __ movptr(Address(rdx, 0), NULL_WORD);
           // No post barrier for NULL
         } else {
-          __ movl(Address(rdx, 0), val);
+          __ movptr(Address(rdx, 0), val);
           __ g1_write_barrier_post(rdx, rax, rcx, rbx, rsi);
         }
         __ restore_bcp();
@@ -152,9 +152,9 @@
     case BarrierSet::CardTableExtension:
       {
         if (val == noreg) {
-          __ movl(obj, (int32_t) NULL_WORD);
+          __ movptr(obj, NULL_WORD);
         } else {
-          __ movl(obj, val);
+          __ movptr(obj, val);
           // flatten object address if needed
           if (!precise || (obj.index() == noreg && obj.disp() == 0)) {
             __ store_check(obj.base());
@@ -168,9 +168,9 @@
     case BarrierSet::ModRef:
     case BarrierSet::Other:
       if (val == noreg) {
-        __ movl(obj, (int32_t) NULL_WORD);
+        __ movptr(obj, NULL_WORD);
       } else {
-        __ movl(obj, val);
+        __ movptr(obj, val);
       }
       break;
     default      :


From Xiaobin.Lu at Sun.COM  Tue Jan 20 10:30:46 2009
From: Xiaobin.Lu at Sun.COM (Xiaobin Lu)
Date: Tue, 20 Jan 2009 10:30:46 -0800
Subject: hg: bsd-port/bsd-port/hotspot: . Add,
	remove and alter casts to get this to compile on Mac OS X (in 32 bit
In-Reply-To: <20090119054340.9623EDBC3@hg.openjdk.java.net>
References: <20090119054340.9623EDBC3@hg.openjdk.java.net>
Message-ID: <49761856.201@Sun.COM>

Hi Greg,

So the fix for 6787106 is not sufficient? I am wondering what the error 
message looked like. I've tried to build on my Mac OS X 10.5.5 before I 
checked in and everything seemed working fine. Sorry if I overlooked 
something.

By the way, do you have a diff for the following check in?

Thanks,

-Xiaobin

On 01/18/09 21:43, glewis at eyesbeyond.com wrote:
> Changeset: b86ce5362022
> Author:    glewis at misty.eyesbeyond.com
> Date:      2009-01-18 21:42 -0800
> URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/b86ce5362022
>
> . Add, remove and alter casts to get this to compile on Mac OS X (in 32 bit
>   mode at least).
>
> ! src/cpu/x86/vm/c1_Runtime1_x86.cpp
> ! src/cpu/x86/vm/interp_masm_x86_32.cpp
> ! src/cpu/x86/vm/interpreterRT_x86_32.cpp
> ! src/cpu/x86/vm/stubGenerator_x86_32.cpp
> ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
> ! src/cpu/x86/vm/templateTable_x86_32.cpp
>
>
>   



From glewis at eyesbeyond.com  Tue Jan 20 12:13:00 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Tue, 20 Jan 2009 12:13:00 -0800
Subject: Additional type corrections
In-Reply-To: <200901201120.59423.kurt@intricatesoftware.com>
References: <200901201120.59423.kurt@intricatesoftware.com>
Message-ID: <20090120201300.GA49354@misty.eyesbeyond.com>

G'day Kurt,

On Tue, Jan 20, 2009 at 11:20:58AM -0500, Kurt Miller wrote:
> Here are more datatype corrections for the bsd-port tree. I've
> tested a variation of this diff on my OpenBSD port (the bsd-port
> tree doesn't build yet on OpenBSD; still a work in progress). These
> should be committed and then we need to extract all the datatype
> corrections for submitting a new bug report for the main tree.
> 
> The changes are as follows:
> - There is no movptr(Address, int32_t) function for x86/32 bit.
> Casting to int32_t for movptr on x86/32 should be avoided. Instead
> cast directly to intptr_t where needed.
> - Several places in the x86/32 code movl is directly used where
> movptr is the correct function. movptr on x86/32 ends up using
> movl but deals with the type variations without the need for
> additional casts.
> - Use NULL_WORD to assign a NULL value to intptr_t instead of
> (intptr_t) NULL

Sorry about that one.

These look good to me (thanks for doing them!) and I've successfully test
compiled with them on Mac OS X with no apparent side effects :).

> diff -r b86ce5362022 src/cpu/x86/vm/interp_masm_x86_32.cpp
> --- a/src/cpu/x86/vm/interp_masm_x86_32.cpp	Sun Jan 18 21:42:26 2009 -0800
> +++ b/src/cpu/x86/vm/interp_masm_x86_32.cpp	Tue Jan 20 10:49:33 2009 -0500
> @@ -149,7 +149,7 @@
>    // Clean up tos value in the thread object
>    movl(tos_addr,  (int32_t) ilgl);
>    movptr(val_addr,  NULL_WORD);
> -  NOT_LP64(movl(val_addr1, (int32_t)NULL_WORD));
> +  NOT_LP64(movptr(val_addr1, NULL_WORD));
>  }
>  
>  
> @@ -473,7 +473,7 @@
>        movptr(Address(rdi, Interpreter::local_tag_offset_in_bytes(n+1)), (intptr_t)frame::TagValue);
>        movptr(Address(rdi, Interpreter::local_tag_offset_in_bytes(n)), (intptr_t)frame::TagValue);
>      } else {
> -      movptr(Address(rdi, Interpreter::local_tag_offset_in_bytes(n)), (int32_t)tag);
> +      movptr(Address(rdi, Interpreter::local_tag_offset_in_bytes(n)), (intptr_t)tag);
>      }
>    }
>  }
> @@ -487,7 +487,7 @@
>                      Interpreter::local_tag_offset_in_bytes(0)), (intptr_t)frame::TagValue);
>      } else {
>        movptr(Address(rdi, idx, Interpreter::stackElementScale(),
> -                               Interpreter::local_tag_offset_in_bytes(0)), (int32_t)tag);
> +                               Interpreter::local_tag_offset_in_bytes(0)), (intptr_t)tag);
>      }
>    }
>  }
> @@ -1319,7 +1319,7 @@
>    int recvr_offset = in_bytes(VirtualCallData::receiver_offset(start_row));
>    set_mdp_data_at(mdp, recvr_offset, receiver);
>    int count_offset = in_bytes(VirtualCallData::receiver_count_offset(start_row));
> -  movptr(reg2, (int32_t)DataLayout::counter_increment);
> +  movptr(reg2, (intptr_t)DataLayout::counter_increment);
>    set_mdp_data_at(mdp, count_offset, reg2);
>    jmp(done);
>  }
> @@ -1458,7 +1458,7 @@
>      test_method_data_pointer(mdp, profile_continue);
>  
>      // Build the base (index * per_case_size_in_bytes()) + case_array_offset_in_bytes()
> -    movptr(reg2, (int32_t)in_bytes(MultiBranchData::per_case_size()));
> +    movptr(reg2, (intptr_t)in_bytes(MultiBranchData::per_case_size()));
>      // index is positive and so should have correct value if this code were
>      // used on 64bits
>      imulptr(index, reg2);
> diff -r b86ce5362022 src/cpu/x86/vm/interpreterRT_x86_32.cpp
> --- a/src/cpu/x86/vm/interpreterRT_x86_32.cpp	Sun Jan 18 21:42:26 2009 -0800
> +++ b/src/cpu/x86/vm/interpreterRT_x86_32.cpp	Tue Jan 20 10:49:33 2009 -0500
> @@ -110,7 +110,7 @@
>    virtual void pass_object() {
>      // pass address of from
>      intptr_t from_addr = (intptr_t)(_from + Interpreter::local_offset_in_bytes(0));
> -    *_to++ = (*(intptr_t*)from_addr == 0) ? (intptr_t) NULL : from_addr;
> +    *_to++ = (*(intptr_t*)from_addr == 0) ? NULL_WORD : from_addr;
>      debug_only(verify_tag(frame::TagReference));
>      _from -= Interpreter::stackElementSize();
>     }
> diff -r b86ce5362022 src/cpu/x86/vm/templateTable_x86_32.cpp
> --- a/src/cpu/x86/vm/templateTable_x86_32.cpp	Sun Jan 18 21:42:26 2009 -0800
> +++ b/src/cpu/x86/vm/templateTable_x86_32.cpp	Tue Jan 20 10:49:33 2009 -0500
> @@ -137,10 +137,10 @@
>          // Do the actual store
>          // noreg means NULL
>          if (val == noreg) {
> -          __ movl(Address(rdx, 0), (int32_t)NULL_WORD);
> +          __ movptr(Address(rdx, 0), NULL_WORD);
>            // No post barrier for NULL
>          } else {
> -          __ movl(Address(rdx, 0), val);
> +          __ movptr(Address(rdx, 0), val);
>            __ g1_write_barrier_post(rdx, rax, rcx, rbx, rsi);
>          }
>          __ restore_bcp();
> @@ -152,9 +152,9 @@
>      case BarrierSet::CardTableExtension:
>        {
>          if (val == noreg) {
> -          __ movl(obj, (int32_t) NULL_WORD);
> +          __ movptr(obj, NULL_WORD);
>          } else {
> -          __ movl(obj, val);
> +          __ movptr(obj, val);
>            // flatten object address if needed
>            if (!precise || (obj.index() == noreg && obj.disp() == 0)) {
>              __ store_check(obj.base());
> @@ -168,9 +168,9 @@
>      case BarrierSet::ModRef:
>      case BarrierSet::Other:
>        if (val == noreg) {
> -        __ movl(obj, (int32_t) NULL_WORD);
> +        __ movptr(obj, NULL_WORD);
>        } else {
> -        __ movl(obj, val);
> +        __ movptr(obj, val);
>        }
>        break;
>      default      :

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From kurt at intricatesoftware.com  Tue Jan 20 12:29:03 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Tue, 20 Jan 2009 20:29:03 +0000
Subject: hg: bsd-port/bsd-port/hotspot: Summary: Additional datatype
	corrections
Message-ID: <20090120202906.014E4DC59@hg.openjdk.java.net>

Changeset: ed1c211cf918
Author:    truk at seraph.intricatesoftware.com
Date:      2009-01-20 15:26 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/ed1c211cf918

Summary: Additional datatype corrections
Reviewed By: glewis

- There is no movptr(Address, int32_t) function for x86/32 bit.
Casting to int32_t for movptr on x86/32 should be avoided. Instead
cast directly to intptr_t where needed.
- Several places in the x86/32 code movl is directly used where
movptr is the correct function. movptr on x86/32 ends up using
movl but deals with the type variations without the need for
additional casts.
- Use NULL_WORD to assign a NULL value to intptr_t instead of
(intptr_t) NULL

! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interpreterRT_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp



From kurt at intricatesoftware.com  Tue Jan 20 12:55:16 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Tue, 20 Jan 2009 15:55:16 -0500
Subject: hg: bsd-port/bsd-port/hotspot: . Add,	remove and alter casts
	to get this to compile on Mac OS X (in 32 bit
In-Reply-To: <49761856.201@Sun.COM>
References: <20090119054340.9623EDBC3@hg.openjdk.java.net>
	<49761856.201@Sun.COM>
Message-ID: <49763A34.3080306@intricatesoftware.com>

Hi Xiaobin,

Sorry to jump in on the thread. Attached is the combined diff of the
remaining cast/datatype changes needed to build on OS X and OpenBSD
that you asked for. It would be great if this can make it into the
main tree.

Thanks,
-Kurt

Xiaobin Lu wrote:
> Hi Greg,
> 
> So the fix for 6787106 is not sufficient? I am wondering what the error 
> message looked like. I've tried to build on my Mac OS X 10.5.5 before I 
> checked in and everything seemed working fine. Sorry if I overlooked 
> something.
> 
> By the way, do you have a diff for the following check in?
> 
> Thanks,
> 
> -Xiaobin
> 
> On 01/18/09 21:43, glewis at eyesbeyond.com wrote:
>> Changeset: b86ce5362022
>> Author:    glewis at misty.eyesbeyond.com
>> Date:      2009-01-18 21:42 -0800
>> URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/b86ce5362022
>>
>> . Add, remove and alter casts to get this to compile on Mac OS X (in 32 bit
>>   mode at least).
>>
>> ! src/cpu/x86/vm/c1_Runtime1_x86.cpp
>> ! src/cpu/x86/vm/interp_masm_x86_32.cpp
>> ! src/cpu/x86/vm/interpreterRT_x86_32.cpp
>> ! src/cpu/x86/vm/stubGenerator_x86_32.cpp
>> ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
>> ! src/cpu/x86/vm/templateTable_x86_32.cpp
>>
>>
>>   
> 
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hotspot_datatype3.diff
Url: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090120/dffb3dfb/hotspot_datatype3.diff 

From kurt at intricatesoftware.com  Tue Jan 20 13:38:48 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Tue, 20 Jan 2009 21:38:48 +0000
Subject: hg: bsd-port/bsd-port/hotspot: Revert bsd-port *includeDB* changes.
Message-ID: <20090120213850.9F3D6DC67@hg.openjdk.java.net>

Changeset: 641d6ebd862a
Author:    kurt
Date:      2009-01-20 16:36 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/641d6ebd862a

Revert bsd-port *includeDB* changes.

! src/share/vm/includeDB_compiler2
! src/share/vm/includeDB_core



From Xiaobin.Lu at Sun.COM  Tue Jan 20 14:22:34 2009
From: Xiaobin.Lu at Sun.COM (Xiaobin Lu)
Date: Tue, 20 Jan 2009 14:22:34 -0800
Subject: hg: bsd-port/bsd-port/hotspot: . Add,
	remove and alter casts to get this to compile on Mac OS X (in 32 bit
In-Reply-To: <49763A34.3080306@intricatesoftware.com>
References: <20090119054340.9623EDBC3@hg.openjdk.java.net>
	<49761856.201@Sun.COM> <49763A34.3080306@intricatesoftware.com>
Message-ID: <49764EAA.7060704@Sun.COM>

I found I missed a few as what in your patch when I did the put back. I 
will try to fix it in the main tree.

Sorry for the inconvenience.

-Xiaobin

On 01/20/09 12:55, Kurt Miller wrote:
> Hi Xiaobin,
>
> Sorry to jump in on the thread. Attached is the combined diff of the
> remaining cast/datatype changes needed to build on OS X and OpenBSD
> that you asked for. It would be great if this can make it into the
> main tree.
>
> Thanks,
> -Kurt
>
> Xiaobin Lu wrote:
>   
>> Hi Greg,
>>
>> So the fix for 6787106 is not sufficient? I am wondering what the error 
>> message looked like. I've tried to build on my Mac OS X 10.5.5 before I 
>> checked in and everything seemed working fine. Sorry if I overlooked 
>> something.
>>
>> By the way, do you have a diff for the following check in?
>>
>> Thanks,
>>
>> -Xiaobin
>>
>> On 01/18/09 21:43, glewis at eyesbeyond.com wrote:
>>     
>>> Changeset: b86ce5362022
>>> Author:    glewis at misty.eyesbeyond.com
>>> Date:      2009-01-18 21:42 -0800
>>> URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/b86ce5362022
>>>
>>> . Add, remove and alter casts to get this to compile on Mac OS X (in 32 bit
>>>   mode at least).
>>>
>>> ! src/cpu/x86/vm/c1_Runtime1_x86.cpp
>>> ! src/cpu/x86/vm/interp_masm_x86_32.cpp
>>> ! src/cpu/x86/vm/interpreterRT_x86_32.cpp
>>> ! src/cpu/x86/vm/stubGenerator_x86_32.cpp
>>> ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
>>> ! src/cpu/x86/vm/templateTable_x86_32.cpp
>>>
>>>
>>>   
>>>       
>>     
>
>   
> ------------------------------------------------------------------------
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090120/3cd861aa/attachment.html 

From kurt at intricatesoftware.com  Tue Jan 20 15:54:55 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Tue, 20 Jan 2009 23:54:55 +0000
Subject: hg: bsd-port/bsd-port/hotspot: Use includeDB corrections from Coleen
	Phillimore @ Sun
Message-ID: <20090120235457.8C846DC9D@hg.openjdk.java.net>

Changeset: 4244db6cd9a9
Author:    kurt
Date:      2009-01-20 18:53 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/4244db6cd9a9

Use includeDB corrections from Coleen Phillimore @ Sun
to correct build without precompiled headers. Fixes build
for gcc 3.3 which OpenBSD uses. Diff from hotspot-dev
list and should make it into the main tree:
http://thread.gmane.org/gmane.comp.java.openjdk.hotspot.devel/1246

! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
! src/share/vm/gc_implementation/includeDB_gc_g1
! src/share/vm/gc_implementation/includeDB_gc_parNew
! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge
! src/share/vm/includeDB_compiler2
! src/share/vm/includeDB_core
! src/share/vm/includeDB_features



From kurt at intricatesoftware.com  Tue Jan 20 16:18:26 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Wed, 21 Jan 2009 00:18:26 +0000
Subject: hg: bsd-port/bsd-port/corba: - Uniformly calculate MB_OF_MEMORY for
	BSD using
Message-ID: <20090121001827.489ABDCAA@hg.openjdk.java.net>

Changeset: b694b3fa68d1
Author:    kurt
Date:      2009-01-20 19:16 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/corba/rev/b694b3fa68d1

- Uniformly calculate MB_OF_MEMORY for BSD using
sysctl -n and awk.
- Make an exception for the maximum amount of memory
the build will use for OpenBSD (due to mmap based
malloc and W^X, only 1 gig of VM is available for
malloc + anon private mmap).

! make/common/shared/Platform.gmk



From kurt at intricatesoftware.com  Tue Jan 20 16:20:44 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Wed, 21 Jan 2009 00:20:44 +0000
Subject: hg: bsd-port/bsd-port/jdk: - Uniformly calculate MB_OF_MEMORY for BSD
	using
Message-ID: <20090121002056.4497ADCB2@hg.openjdk.java.net>

Changeset: d9b944d764ab
Author:    kurt
Date:      2009-01-20 19:19 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/d9b944d764ab

- Uniformly calculate MB_OF_MEMORY for BSD using
sysctl -n and awk.
- Make an exception for the maximum amount of memory
the build will use for OpenBSD (due to mmap based
malloc and W^X, only 1 gig of VM is available for
malloc + anon private mmap).

! make/common/shared/Platform.gmk



From kurt at intricatesoftware.com  Tue Jan 20 19:49:19 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Tue, 20 Jan 2009 22:49:19 -0500
Subject: A patch for src/solaris/classes/sun/awt/X11/XKeysym.java
In-Reply-To: <9BF2F932-6819-4EA2-922C-7194A8F2FFD9@sun.com>
References: <9BF2F932-6819-4EA2-922C-7194A8F2FFD9@sun.com>
Message-ID: <49769B3F.8070405@intricatesoftware.com>

Hi Max,

I too am not an X11/awt expert. I looked over the patch and some
of the related code. 16 == XConstants.Mod2Mask, but looking at

src/solaris/classes/sun/awt/X11/XToolkit.java

makes me believe hard-coding it here is not correct. On my system
mod2 is NumLock but on OS X it is Command (use xmodmap -p to check).
To further complicate things XK_Meta_L is Alt normally but on OS X
it is the Command key.  I'm not sure of the correct solution to use
to resolve the issues. One work-around can be found here though:

http://extrabright.com/blog/2007/02/03/better-keyboard-shortcut-for-mac-x11-apps/

Regards,
-Kurt

Max (Weijun) Wang wrote:
> Hi, BSD Hackers
> 
> I'm using the bsd-port openjdk to run NetBeans on my MacBook. There's  
> a problem that when you press Command+X in the editor, besides the  
> keyboard shortcut being executed, the letter "X" itself goes into the  
> edited file.
> 
> I've coined the following patch and at least NetBeans works fine now.
> 
> diff --git a/src/solaris/classes/sun/awt/X11/XKeysym.java b/src/ 
> solaris/classes/sun/awt/X11/XKeysym.java
> --- a/src/solaris/classes/sun/awt/X11/XKeysym.java
> +++ b/src/solaris/classes/sun/awt/X11/XKeysym.java
> @@ -70,7 +70,7 @@
>           /* First check for Latin-1 characters (1:1 mapping) */
>           if ((ks >= 0x0020 && ks <= 0x007e) ||
>               (ks >= 0x00a0 && ks <= 0x00ff)) {
> -            if( (state & XConstants.ControlMask) != 0 ) {
> +            if( (state & XConstants.ControlMask) != 0 || (state &  
> 16) != 0 ) {
>                   if ((ks >= 'A' && ks <= ']') || (ks == '_') ||
>                       (ks >= 'a' && ks <='z')) {
>                       ks &= 0x1F;
> 
> I'm neither a BSD nor an X11/awt expert, so I'm completely not sure if  
> this really fixes the problem or has broken other things.
> 
> Thanks
> Max
> 
> 



From kurt at intricatesoftware.com  Tue Jan 20 19:51:09 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Tue, 20 Jan 2009 22:51:09 -0500
Subject: java.nio and SelectionKey.interestOps(int i)
In-Reply-To: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>
References: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>
Message-ID: <49769BAD.2090009@intricatesoftware.com>

Hello Martin,

Can you post a minimal test case that reproduces the issue?

Thanks,
-Kurt


Martin Kihlgren wrote:
> Hello list!
> 
> I have this problem that I thought maybe you could help explaining.
> 
> I have this application, where a server thread loops around a
> select(), and then does stuff to the different SelectableChannels that
> pops out from the Selector.
> 
> If something is read from a channel, for example, I send it to a
> handler. And if the handler wants to respond in some way, it adds it
> to a queue and then does interestOps(interestOps() &
> SelectionKey.OP_WRITE) on its SelectionKey. Then it does wakeup() on
> its Selector.
> 
> In Sun's java 6 for linux, this works beautifully. The Selector wakes
> up, does another select, and finds that suddenly this
> SelectableChannel wants to be (and can be) written to.
> 
> In SoyLatte, however, nothing happens! No matter if I wake the
> selector up one or many times, it doesn't recognize that the
> SelectableChannel and its SelectionKey is interested in OP_WRITE.
> 
> Any ideas?
> 
> regards,
> //Martin Kihlgren
> 



From Weijun.Wang at Sun.COM  Tue Jan 20 22:25:39 2009
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Wed, 21 Jan 2009 14:25:39 +0800
Subject: A patch for src/solaris/classes/sun/awt/X11/XKeysym.java
In-Reply-To: <49769B3F.8070405@intricatesoftware.com>
References: <9BF2F932-6819-4EA2-922C-7194A8F2FFD9@sun.com>
	<49769B3F.8070405@intricatesoftware.com>
Message-ID: <BD53EACD-0D29-498D-8E84-5BBC92DEF546@Sun.COM>

> to resolve the issues. One work-around can be found here though:
>
> http://extrabright.com/blog/2007/02/03/better-keyboard-shortcut-for-mac-x11-apps/

This workaround maps both Meta keys to Ctrl, which might be good for  
OpenOffice (the X11 version) where only Ctrl-X keyboard shortcuts are  
defined. In NetBeans, both Meta-X and Ctrl-X keys are defined, and you  
lost the function of Meta+X after this match. For example, both Ctrl-G  
and Meta-G are now "Go to Line".

Thanks
Max

On Jan 21, 2009, at 11:49 AM, Kurt Miller wrote:

> Hi Max,
>
> I too am not an X11/awt expert. I looked over the patch and some
> of the related code. 16 == XConstants.Mod2Mask, but looking at
>
> src/solaris/classes/sun/awt/X11/XToolkit.java
>
> makes me believe hard-coding it here is not correct. On my system
> mod2 is NumLock but on OS X it is Command (use xmodmap -p to check).
> To further complicate things XK_Meta_L is Alt normally but on OS X
> it is the Command key.  I'm not sure of the correct solution to use
> to resolve the issues. One work-around can be found here though:
>
> http://extrabright.com/blog/2007/02/03/better-keyboard-shortcut-for-mac-x11-apps/
>
> Regards,
> -Kurt
>
> Max (Weijun) Wang wrote:
>> Hi, BSD Hackers
>>
>> I'm using the bsd-port openjdk to run NetBeans on my MacBook. There's
>> a problem that when you press Command+X in the editor, besides the
>> keyboard shortcut being executed, the letter "X" itself goes into the
>> edited file.
>>
>> I've coined the following patch and at least NetBeans works fine now.
>>
>> diff --git a/src/solaris/classes/sun/awt/X11/XKeysym.java b/src/
>> solaris/classes/sun/awt/X11/XKeysym.java
>> --- a/src/solaris/classes/sun/awt/X11/XKeysym.java
>> +++ b/src/solaris/classes/sun/awt/X11/XKeysym.java
>> @@ -70,7 +70,7 @@
>>          /* First check for Latin-1 characters (1:1 mapping) */
>>          if ((ks >= 0x0020 && ks <= 0x007e) ||
>>              (ks >= 0x00a0 && ks <= 0x00ff)) {
>> -            if( (state & XConstants.ControlMask) != 0 ) {
>> +            if( (state & XConstants.ControlMask) != 0 || (state &
>> 16) != 0 ) {
>>                  if ((ks >= 'A' && ks <= ']') || (ks == '_') ||
>>                      (ks >= 'a' && ks <='z')) {
>>                      ks &= 0x1F;
>>
>> I'm neither a BSD nor an X11/awt expert, so I'm completely not sure  
>> if
>> this really fixes the problem or has broken other things.
>>
>> Thanks
>> Max
>>
>>
>



From zondolfin at gmail.com  Wed Jan 21 01:18:47 2009
From: zondolfin at gmail.com (Martin Kihlgren)
Date: Wed, 21 Jan 2009 10:18:47 +0100
Subject: java.nio and SelectionKey.interestOps(int i)
In-Reply-To: <49769BAD.2090009@intricatesoftware.com>
References: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>
	<49769BAD.2090009@intricatesoftware.com>
Message-ID: <27acba740901210118x5f39ca1cj9b508dbc91eec9b3@mail.gmail.com>

Of course!

I will attach the code, and here is my results when I run it on two
different machines:

On my linux box:
------------------------------8<---------------------------
[0:zond at cthulhu ~/tmp]$uname -a
Linux cthulhu 2.6.23 #3 SMP Mon Jan 21 10:44:04 CET 2008 i686 GNU/Linux
[0:zond at cthulhu ~/tmp]$java -version
java version "1.6.0_0"
OpenJDK  Runtime Environment (build 1.6.0_0-b11)
OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
[0:zond at cthulhu ~/tmp]$md5sum SetInterestOpsTest.java
e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
[0:zond at cthulhu ~/tmp]$javac SetInterestOpsTest.java
[0:zond at cthulhu ~/tmp]$java SetInterestOpsTest
Connecter connected
Connecter sent test1
Listener accepted connection
Listener read test1
Listener wrote test2
Connecter received test2
[0:zond at cthulhu ~/tmp]$
------------------------------8<---------------------------

On my OS X Tiger box:
------------------------------8<---------------------------
[0:zond at sharkattack ~/tmp]$uname -a
Darwin sharkattack.troja.ath.cx 8.11.1 Darwin Kernel Version 8.11.1:
Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
i386
[0:zond at sharkattack ~/tmp]$java -version
java version "1.6.0_03-p3"
Java(TM) SE Runtime Environment (build
1.6.0_03-p3-landonf_19_aug_2008_14_55-b00)
Java HotSpot(TM) Server VM (build
1.6.0_03-p3-landonf_19_aug_2008_14_55-b00, mixed mode)
[0:zond at sharkattack ~/tmp]$md5sum SetInterestOpsTest.java
e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
[0:zond at sharkattack ~/tmp]$javac SetInterestOpsTest.java
[0:zond at sharkattack ~/tmp]$java SetInterestOpsTest
Connecter connected
Connecter sent test1
Listener accepted connection
Listener read test1
^C[130:zond at sharkattack ~/tmp]$
------------------------------8<---------------------------

regards,
//Martin Kihlgren

On Wed, Jan 21, 2009 at 4:51 AM, Kurt Miller <kurt at intricatesoftware.com> wrote:
> Hello Martin,
>
> Can you post a minimal test case that reproduces the issue?
>
> Thanks,
> -Kurt
>
>
> Martin Kihlgren wrote:
>> Hello list!
>>
>> I have this problem that I thought maybe you could help explaining.
>>
>> I have this application, where a server thread loops around a
>> select(), and then does stuff to the different SelectableChannels that
>> pops out from the Selector.
>>
>> If something is read from a channel, for example, I send it to a
>> handler. And if the handler wants to respond in some way, it adds it
>> to a queue and then does interestOps(interestOps() &
>> SelectionKey.OP_WRITE) on its SelectionKey. Then it does wakeup() on
>> its Selector.
>>
>> In Sun's java 6 for linux, this works beautifully. The Selector wakes
>> up, does another select, and finds that suddenly this
>> SelectableChannel wants to be (and can be) written to.
>>
>> In SoyLatte, however, nothing happens! No matter if I wake the
>> selector up one or many times, it doesn't recognize that the
>> SelectableChannel and its SelectionKey is interested in OP_WRITE.
>>
>> Any ideas?
>>
>> regards,
>> //Martin Kihlgren
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SetInterestOpsTest.java
Type: text/x-java
Size: 3208 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090121/a63e25db/SetInterestOpsTest.java 

From christos at zoulas.com  Wed Jan 21 05:14:58 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 21 Jan 2009 08:14:58 -0500
Subject: hg: bsd-port/bsd-port/jdk: - Uniformly calculate MB_OF_MEMORY for
	BSD using
In-Reply-To: <20090121002056.4497ADCB2@hg.openjdk.java.net>
	from kurt@intricatesoftware.com (Jan 21, 12:20am)
Message-ID: <20090121131458.3D8045654E@rebar.astron.com>

On Jan 21, 12:20am, kurt at intricatesoftware.com (kurt at intricatesoftware.com) wrote:
-- Subject: hg: bsd-port/bsd-port/jdk: - Uniformly calculate MB_OF_MEMORY for

| Changeset: d9b944d764ab
| Author:    kurt
| Date:      2009-01-20 19:19 -0500
| URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/d9b944d764ab
| 
| - Uniformly calculate MB_OF_MEMORY for BSD using
| sysctl -n and awk.
| - Make an exception for the maximum amount of memory
| the build will use for OpenBSD (due to mmap based
| malloc and W^X, only 1 gig of VM is available for
| malloc + anon private mmap).

I had ~the same patch!

christos


From kurt at intricatesoftware.com  Wed Jan 21 11:05:30 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Wed, 21 Jan 2009 14:05:30 -0500
Subject: A patch for src/solaris/classes/sun/awt/X11/XKeysym.java
In-Reply-To: <BD53EACD-0D29-498D-8E84-5BBC92DEF546@Sun.COM>
References: <9BF2F932-6819-4EA2-922C-7194A8F2FFD9@sun.com>
	<49769B3F.8070405@intricatesoftware.com>
	<BD53EACD-0D29-498D-8E84-5BBC92DEF546@Sun.COM>
Message-ID: <497771FA.4050809@intricatesoftware.com>

Ahh ok that wont help you. This may be the correct fix but I worry about
unintended side effects since I don't know this code very well. If the
below patch works for you, could you check with the awt devs at Sun to
see if it is correct and file a bug report for getting into the main
tree?

I didn't find any obvious side effects on OpenBSD - Alt still worked
as expected.

diff -r d9b944d764ab src/solaris/classes/sun/awt/X11/XKeysym.java
--- a/src/solaris/classes/sun/awt/X11/XKeysym.java      Tue Jan 20
19:19:27 2009 -0500
+++ b/src/solaris/classes/sun/awt/X11/XKeysym.java      Wed Jan 21
14:03:27 2009 -0500
@@ -70,7 +70,8 @@
         /* First check for Latin-1 characters (1:1 mapping) */
         if ((ks >= 0x0020 && ks <= 0x007e) ||
             (ks >= 0x00a0 && ks <= 0x00ff)) {
-            if( (state & XConstants.ControlMask) != 0 ) {
+            if( (state & XConstants.ControlMask) != 0 ||
+                (state & XToolkit.metaMask) != 0) {
                 if ((ks >= 'A' && ks <= ']') || (ks == '_') ||
                     (ks >= 'a' && ks <='z')) {
                     ks &= 0x1F;

Max (Weijun) Wang wrote:
>> to resolve the issues. One work-around can be found here though:
>>
>> http://extrabright.com/blog/2007/02/03/better-keyboard-shortcut-for-mac-x11-apps/
>>
> 
> This workaround maps both Meta keys to Ctrl, which might be good for
> OpenOffice (the X11 version) where only Ctrl-X keyboard shortcuts are
> defined. In NetBeans, both Meta-X and Ctrl-X keys are defined, and you
> lost the function of Meta+X after this match. For example, both Ctrl-G
> and Meta-G are now "Go to Line".
> 
> Thanks
> Max
> 
> On Jan 21, 2009, at 11:49 AM, Kurt Miller wrote:
> 
>> Hi Max,
>>
>> I too am not an X11/awt expert. I looked over the patch and some
>> of the related code. 16 == XConstants.Mod2Mask, but looking at
>>
>> src/solaris/classes/sun/awt/X11/XToolkit.java
>>
>> makes me believe hard-coding it here is not correct. On my system
>> mod2 is NumLock but on OS X it is Command (use xmodmap -p to check).
>> To further complicate things XK_Meta_L is Alt normally but on OS X
>> it is the Command key.  I'm not sure of the correct solution to use
>> to resolve the issues. One work-around can be found here though:
>>
>> http://extrabright.com/blog/2007/02/03/better-keyboard-shortcut-for-mac-x11-apps/
>>
>>
>> Regards,
>> -Kurt
>>
>> Max (Weijun) Wang wrote:
>>> Hi, BSD Hackers
>>>
>>> I'm using the bsd-port openjdk to run NetBeans on my MacBook. There's
>>> a problem that when you press Command+X in the editor, besides the
>>> keyboard shortcut being executed, the letter "X" itself goes into the
>>> edited file.
>>>
>>> I've coined the following patch and at least NetBeans works fine now.
>>>
>>> diff --git a/src/solaris/classes/sun/awt/X11/XKeysym.java b/src/
>>> solaris/classes/sun/awt/X11/XKeysym.java
>>> --- a/src/solaris/classes/sun/awt/X11/XKeysym.java
>>> +++ b/src/solaris/classes/sun/awt/X11/XKeysym.java
>>> @@ -70,7 +70,7 @@
>>>          /* First check for Latin-1 characters (1:1 mapping) */
>>>          if ((ks >= 0x0020 && ks <= 0x007e) ||
>>>              (ks >= 0x00a0 && ks <= 0x00ff)) {
>>> -            if( (state & XConstants.ControlMask) != 0 ) {
>>> +            if( (state & XConstants.ControlMask) != 0 || (state &
>>> 16) != 0 ) {
>>>                  if ((ks >= 'A' && ks <= ']') || (ks == '_') ||
>>>                      (ks >= 'a' && ks <='z')) {
>>>                      ks &= 0x1F;
>>>
>>> I'm neither a BSD nor an X11/awt expert, so I'm completely not sure if
>>> this really fixes the problem or has broken other things.
>>>
>>> Thanks
>>> Max
>>>
>>>
>>
> 




From kurt at intricatesoftware.com  Wed Jan 21 13:10:40 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Wed, 21 Jan 2009 16:10:40 -0500
Subject: java.nio and SelectionKey.interestOps(int i)
In-Reply-To: <27acba740901210118x5f39ca1cj9b508dbc91eec9b3@mail.gmail.com>
References: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>	
	<49769BAD.2090009@intricatesoftware.com>
	<27acba740901210118x5f39ca1cj9b508dbc91eec9b3@mail.gmail.com>
Message-ID: <49778F50.4050409@intricatesoftware.com>

Great, thank you. A quick test on OpenBSD and FreeBSD shows that
it works as expected on OpenBSD but fails the same as OS X on FreeBSD.

It may be a week or two before I find time to debug it on FreeBSD.
Thanks for the report and test case.

Martin Kihlgren wrote:
> Of course!
> 
> I will attach the code, and here is my results when I run it on two
> different machines:
> 
> On my linux box:
> ------------------------------8<---------------------------
> [0:zond at cthulhu ~/tmp]$uname -a
> Linux cthulhu 2.6.23 #3 SMP Mon Jan 21 10:44:04 CET 2008 i686 GNU/Linux
> [0:zond at cthulhu ~/tmp]$java -version
> java version "1.6.0_0"
> OpenJDK  Runtime Environment (build 1.6.0_0-b11)
> OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
> [0:zond at cthulhu ~/tmp]$md5sum SetInterestOpsTest.java
> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
> [0:zond at cthulhu ~/tmp]$javac SetInterestOpsTest.java
> [0:zond at cthulhu ~/tmp]$java SetInterestOpsTest
> Connecter connected
> Connecter sent test1
> Listener accepted connection
> Listener read test1
> Listener wrote test2
> Connecter received test2
> [0:zond at cthulhu ~/tmp]$
> ------------------------------8<---------------------------
> 
> On my OS X Tiger box:
> ------------------------------8<---------------------------
> [0:zond at sharkattack ~/tmp]$uname -a
> Darwin sharkattack.troja.ath.cx 8.11.1 Darwin Kernel Version 8.11.1:
> Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
> i386
> [0:zond at sharkattack ~/tmp]$java -version
> java version "1.6.0_03-p3"
> Java(TM) SE Runtime Environment (build
> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00)
> Java HotSpot(TM) Server VM (build
> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00, mixed mode)
> [0:zond at sharkattack ~/tmp]$md5sum SetInterestOpsTest.java
> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
> [0:zond at sharkattack ~/tmp]$javac SetInterestOpsTest.java
> [0:zond at sharkattack ~/tmp]$java SetInterestOpsTest
> Connecter connected
> Connecter sent test1
> Listener accepted connection
> Listener read test1
> ^C[130:zond at sharkattack ~/tmp]$
> ------------------------------8<---------------------------
> 
> regards,
> //Martin Kihlgren
> 
> On Wed, Jan 21, 2009 at 4:51 AM, Kurt Miller <kurt at intricatesoftware.com> wrote:
>> Hello Martin,
>>
>> Can you post a minimal test case that reproduces the issue?
>>
>> Thanks,
>> -Kurt
>>
>>
>> Martin Kihlgren wrote:
>>> Hello list!
>>>
>>> I have this problem that I thought maybe you could help explaining.
>>>
>>> I have this application, where a server thread loops around a
>>> select(), and then does stuff to the different SelectableChannels that
>>> pops out from the Selector.
>>>
>>> If something is read from a channel, for example, I send it to a
>>> handler. And if the handler wants to respond in some way, it adds it
>>> to a queue and then does interestOps(interestOps() &
>>> SelectionKey.OP_WRITE) on its SelectionKey. Then it does wakeup() on
>>> its Selector.
>>>
>>> In Sun's java 6 for linux, this works beautifully. The Selector wakes
>>> up, does another select, and finds that suddenly this
>>> SelectableChannel wants to be (and can be) written to.
>>>
>>> In SoyLatte, however, nothing happens! No matter if I wake the
>>> selector up one or many times, it doesn't recognize that the
>>> SelectableChannel and its SelectionKey is interested in OP_WRITE.
>>>
>>> Any ideas?
>>>
>>> regards,
>>> //Martin Kihlgren
>>>
>>



From kurt at intricatesoftware.com  Wed Jan 21 13:40:49 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Wed, 21 Jan 2009 16:40:49 -0500
Subject: hg: bsd-port/bsd-port/jdk: - Uniformly calculate MB_OF_MEMORY
	for BSD using
In-Reply-To: <20090121131458.3D8045654E@rebar.astron.com>
References: <20090121131458.3D8045654E@rebar.astron.com>
Message-ID: <49779661.7080508@intricatesoftware.com>

Christos Zoulas wrote:
> On Jan 21, 12:20am, kurt at intricatesoftware.com (kurt at intricatesoftware.com) wrote:
> -- Subject: hg: bsd-port/bsd-port/jdk: - Uniformly calculate MB_OF_MEMORY for
> 
> | Changeset: d9b944d764ab
> | Author:    kurt
> | Date:      2009-01-20 19:19 -0500
> | URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/d9b944d764ab
> | 
> | - Uniformly calculate MB_OF_MEMORY for BSD using
> | sysctl -n and awk.
> | - Make an exception for the maximum amount of memory
> | the build will use for OpenBSD (due to mmap based
> | malloc and W^X, only 1 gig of VM is available for
> | malloc + anon private mmap).
> 
> I had ~the same patch!

Hi Christos!

Does that mean you're working on NetBSD support now? :-)

-Kurt


From kurt at intricatesoftware.com  Wed Jan 21 15:45:53 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Wed, 21 Jan 2009 23:45:53 +0000
Subject: hg: bsd-port/bsd-port/jdk: For OpenBSD use file:///dev/arandom for
	the default securerandom.source
Message-ID: <20090121234604.ED05ADD80@hg.openjdk.java.net>

Changeset: e2f22afd9638
Author:    kurt
Date:      2009-01-21 18:37 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/e2f22afd9638

For OpenBSD use file:///dev/arandom for the default securerandom.source
property. This is because /dev/random is reserved for hardware random
generators on OpenBSD and the Solaris/Linux default of file:/dev/urandom
causes /dev/random to be used for both sun.security.provider.SeedGenerator
and sun.security.provider.NativePRNG. I don't see a clean way to enable
NativePRNG on OpenBSD without patching shared code that hard-codes the
file:/dev/random and file:/dev/urandom strings.

! make/java/security/Makefile
+ src/share/lib/security/java.security-openbsd



From Weijun.Wang at Sun.COM  Wed Jan 21 20:40:39 2009
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Thu, 22 Jan 2009 12:40:39 +0800
Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display
In-Reply-To: <fee4d890812191626i22ff982dra1740b6eeb082784@mail.gmail.com>
References: <fee4d890812191626i22ff982dra1740b6eeb082784@mail.gmail.com>
Message-ID: <5294BFC6-8690-4894-A694-E79E8A3D8867@sun.com>

It seems even the simplest networking code fails.

$ cat ~/tmp/A.java
class  A {
   public static void main(String[] args) throws Exception {
     new java.net.ServerSocket(10000).accept();
   }
}

$ java A
Exception in thread "main" java.net.SocketException: Invalid argument
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at  
java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java: 
364)
	at java.net.ServerSocket.implAccept(ServerSocket.java:513)
	at java.net.ServerSocket.accept(ServerSocket.java:481)
	at A.main(A.java:3)

Don't know why. The problem comes from C function NET_Accept, which is  
mentioned in these files:

    jdk/make/java/net/FILES_c.gmk
       Include bsd_close.c when OS_VENDOR is FreeBSD
    jdk/src/solaris/native/java/net/bsd_close.c
       Defines a version of NET_Accept
    jdk/src/solaris/native/java/net/net_util_md.h
       Declares NET_Accept, using impl of bsd_close.c or JVM_Accept  
depending on defined(__FreeBSD__)

I'm not familiar with BSD C coding. Anyway on Mac OS_VENDOR is Apple.

Max

On Dec 20, 2008, at 8:26 AM, Michael Franz wrote:

> Hi,
>
> I am running NetBeans on OS X using OpenJDK 7.  This uses the X11  
> implementation as there is no native Cocoa/Carbon Swing  
> implementation.  There are a few quirks that I would like to  
> mention, maybe someone can indicate what part of the code these  
> issue are in.
>
> 1.  Menus - the cursor is sometimes 1 line item below what is  
> highlighted
> 2.  Dual display - opening  new dialogs are centered between the  
> displays (not the current display netbeans is in).
> 3. The log file has many of these exceptions:
> java.net.SocketException: Invalid argument
>         at java.net.PlainSocketImpl.socketAccept(Native Method)
>         at  
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java: 
> 364)
>         at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>         at java.net.ServerSocket.accept(ServerSocket.java:481)
>         at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010)
>
>
> Michael
>



From Weijun.Wang at Sun.COM  Wed Jan 21 21:52:47 2009
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Thu, 22 Jan 2009 13:52:47 +0800
Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display
In-Reply-To: <5294BFC6-8690-4894-A694-E79E8A3D8867@sun.com>
References: <fee4d890812191626i22ff982dra1740b6eeb082784@mail.gmail.com>
	<5294BFC6-8690-4894-A694-E79E8A3D8867@sun.com>
Message-ID: <7AACCE5C-19BF-46D2-81A1-70B76709FBCD@sun.com>

Sorry, my previous analysis is wrong. The problem seems to be in  
NET_timeout.

I noticed some lines in hotspot/src/os/bsd/vm/hpi_bsd.hpp
http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/file/4244db6cd9a9/src/os/bsd/vm/hpi_bsd.hpp

#ifdef __APPLE__
     // XXXDARWIN: poll() appears non-interruptable on Leopard:  
Thread.interrupt() failed to
     // cause interrupt. Does poll work at all on Tiger? Needs  
investigation.
     fd_set fdset;
     struct timeval seltv;

     FD_ZERO(&fdset);
     FD_SET(fd, &fdset);

     seltv.tv_sec = timeout / 1000;
     seltv.tv_usec = (timeout % 1000) * 1000;

     INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,  
&seltv), res, os::Bsd::clear_interrupted);
#else
     struct pollfd pfd;

     pfd.fd = fd;
     pfd.events = POLLIN | POLLERR;

     INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res,  
os::Bsd::clear_interrupted);
#endif

In fact, if I remove the #if part and revert to the #else block.  
Everything works again. I'm using OS X 10.5.6 on a 32bit Core Duo  
MacBook.

Thanks
Max

On Jan 22, 2009, at 12:40 PM, Max (Weijun) Wang wrote:

> It seems even the simplest networking code fails.
>
> $ cat ~/tmp/A.java
> class  A {
>   public static void main(String[] args) throws Exception {
>     new java.net.ServerSocket(10000).accept();
>   }
> }
>
> $ java A
> Exception in thread "main" java.net.SocketException: Invalid argument
> 	at java.net.PlainSocketImpl.socketAccept(Native Method)
> 	at
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
> 364)
> 	at java.net.ServerSocket.implAccept(ServerSocket.java:513)
> 	at java.net.ServerSocket.accept(ServerSocket.java:481)
> 	at A.main(A.java:3)
>
> Don't know why. The problem comes from C function NET_Accept, which is
> mentioned in these files:
>
>    jdk/make/java/net/FILES_c.gmk
>       Include bsd_close.c when OS_VENDOR is FreeBSD
>    jdk/src/solaris/native/java/net/bsd_close.c
>       Defines a version of NET_Accept
>    jdk/src/solaris/native/java/net/net_util_md.h
>       Declares NET_Accept, using impl of bsd_close.c or JVM_Accept
> depending on defined(__FreeBSD__)
>
> I'm not familiar with BSD C coding. Anyway on Mac OS_VENDOR is Apple.
>
> Max
>
> On Dec 20, 2008, at 8:26 AM, Michael Franz wrote:
>
>> Hi,
>>
>> I am running NetBeans on OS X using OpenJDK 7.  This uses the X11
>> implementation as there is no native Cocoa/Carbon Swing
>> implementation.  There are a few quirks that I would like to
>> mention, maybe someone can indicate what part of the code these
>> issue are in.
>>
>> 1.  Menus - the cursor is sometimes 1 line item below what is
>> highlighted
>> 2.  Dual display - opening  new dialogs are centered between the
>> displays (not the current display netbeans is in).
>> 3. The log file has many of these exceptions:
>> java.net.SocketException: Invalid argument
>>        at java.net.PlainSocketImpl.socketAccept(Native Method)
>>        at
>> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
>> 364)
>>        at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>>        at java.net.ServerSocket.accept(ServerSocket.java:481)
>>        at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010)
>>
>>
>> Michael
>>
>
>



From Weijun.Wang at Sun.COM  Wed Jan 21 22:20:13 2009
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Thu, 22 Jan 2009 14:20:13 +0800
Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display
In-Reply-To: <7AACCE5C-19BF-46D2-81A1-70B76709FBCD@sun.com>
References: <fee4d890812191626i22ff982dra1740b6eeb082784@mail.gmail.com>
	<5294BFC6-8690-4894-A694-E79E8A3D8867@sun.com>
	<7AACCE5C-19BF-46D2-81A1-70B76709FBCD@sun.com>
Message-ID: <2831F9FC-44B1-4581-AC89-E21717725CAE@sun.com>

The original #ifdef block has not taken care of timeout == -1. The  
following codes work:

     if (timeout > 0) {
         seltv.tv_sec = timeout / 1000;
         seltv.tv_usec = (timeout % 1000) * 1000;

         INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,  
&seltv), res, os::Bsd::clear_interrupted);
     } else {
         INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,  
NULL), res, os::Bsd::clear_interrupted);
     }

Max

On Jan 22, 2009, at 1:52 PM, Max (Weijun) Wang wrote:

> Sorry, my previous analysis is wrong. The problem seems to be in
> NET_timeout.
>
> I noticed some lines in hotspot/src/os/bsd/vm/hpi_bsd.hpp
> http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/file/4244db6cd9a9/src/os/bsd/vm/hpi_bsd.hpp
>
> #ifdef __APPLE__
>     // XXXDARWIN: poll() appears non-interruptable on Leopard:
> Thread.interrupt() failed to
>     // cause interrupt. Does poll work at all on Tiger? Needs
> investigation.
>     fd_set fdset;
>     struct timeval seltv;
>
>     FD_ZERO(&fdset);
>     FD_SET(fd, &fdset);
>
>     seltv.tv_sec = timeout / 1000;
>     seltv.tv_usec = (timeout % 1000) * 1000;
>
>     INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,
> &seltv), res, os::Bsd::clear_interrupted);
> #else
>     struct pollfd pfd;
>
>     pfd.fd = fd;
>     pfd.events = POLLIN | POLLERR;
>
>     INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res,
> os::Bsd::clear_interrupted);
> #endif
>
> In fact, if I remove the #if part and revert to the #else block.
> Everything works again. I'm using OS X 10.5.6 on a 32bit Core Duo
> MacBook.
>
> Thanks
> Max
>
> On Jan 22, 2009, at 12:40 PM, Max (Weijun) Wang wrote:
>
>> It seems even the simplest networking code fails.
>>
>> $ cat ~/tmp/A.java
>> class  A {
>>  public static void main(String[] args) throws Exception {
>>    new java.net.ServerSocket(10000).accept();
>>  }
>> }
>>
>> $ java A
>> Exception in thread "main" java.net.SocketException: Invalid argument
>> 	at java.net.PlainSocketImpl.socketAccept(Native Method)
>> 	at
>> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
>> 364)
>> 	at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>> 	at java.net.ServerSocket.accept(ServerSocket.java:481)
>> 	at A.main(A.java:3)
>>
>> Don't know why. The problem comes from C function NET_Accept, which  
>> is
>> mentioned in these files:
>>
>>   jdk/make/java/net/FILES_c.gmk
>>      Include bsd_close.c when OS_VENDOR is FreeBSD
>>   jdk/src/solaris/native/java/net/bsd_close.c
>>      Defines a version of NET_Accept
>>   jdk/src/solaris/native/java/net/net_util_md.h
>>      Declares NET_Accept, using impl of bsd_close.c or JVM_Accept
>> depending on defined(__FreeBSD__)
>>
>> I'm not familiar with BSD C coding. Anyway on Mac OS_VENDOR is Apple.
>>
>> Max
>>
>> On Dec 20, 2008, at 8:26 AM, Michael Franz wrote:
>>
>>> Hi,
>>>
>>> I am running NetBeans on OS X using OpenJDK 7.  This uses the X11
>>> implementation as there is no native Cocoa/Carbon Swing
>>> implementation.  There are a few quirks that I would like to
>>> mention, maybe someone can indicate what part of the code these
>>> issue are in.
>>>
>>> 1.  Menus - the cursor is sometimes 1 line item below what is
>>> highlighted
>>> 2.  Dual display - opening  new dialogs are centered between the
>>> displays (not the current display netbeans is in).
>>> 3. The log file has many of these exceptions:
>>> java.net.SocketException: Invalid argument
>>>       at java.net.PlainSocketImpl.socketAccept(Native Method)
>>>       at
>>> java 
>>> .net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
>>> 364)
>>>       at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>>>       at java.net.ServerSocket.accept(ServerSocket.java:481)
>>>       at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010)
>>>
>>>
>>> Michael
>>>
>>
>>
>
>



From mvfranz at gmail.com  Thu Jan 22 03:59:42 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Thu, 22 Jan 2009 06:59:42 -0500
Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display
In-Reply-To: <2831F9FC-44B1-4581-AC89-E21717725CAE@sun.com>
References: <fee4d890812191626i22ff982dra1740b6eeb082784@mail.gmail.com>
	<5294BFC6-8690-4894-A694-E79E8A3D8867@sun.com>
	<7AACCE5C-19BF-46D2-81A1-70B76709FBCD@sun.com>
	<2831F9FC-44B1-4581-AC89-E21717725CAE@sun.com>
Message-ID: <fee4d890901220359i35c4d0a8le658273770246231@mail.gmail.com>

Max,

Did you see this thread?
http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000229.html

Michael

On Thu, Jan 22, 2009 at 1:20 AM, Max (Weijun) Wang <Weijun.Wang at sun.com>wrote:

> The original #ifdef block has not taken care of timeout == -1. The
> following codes work:
>
>    if (timeout > 0) {
>        seltv.tv_sec = timeout / 1000;
>        seltv.tv_usec = (timeout % 1000) * 1000;
>
>        INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL, &seltv),
> res, os::Bsd::clear_interrupted);
>    } else {
>        INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL, NULL),
> res, os::Bsd::clear_interrupted);
>    }
>
> Max
>
>
> On Jan 22, 2009, at 1:52 PM, Max (Weijun) Wang wrote:
>
>  Sorry, my previous analysis is wrong. The problem seems to be in
>> NET_timeout.
>>
>> I noticed some lines in hotspot/src/os/bsd/vm/hpi_bsd.hpp
>>
>> http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/file/4244db6cd9a9/src/os/bsd/vm/hpi_bsd.hpp
>>
>> #ifdef __APPLE__
>>    // XXXDARWIN: poll() appears non-interruptable on Leopard:
>> Thread.interrupt() failed to
>>    // cause interrupt. Does poll work at all on Tiger? Needs
>> investigation.
>>    fd_set fdset;
>>    struct timeval seltv;
>>
>>    FD_ZERO(&fdset);
>>    FD_SET(fd, &fdset);
>>
>>    seltv.tv_sec = timeout / 1000;
>>    seltv.tv_usec = (timeout % 1000) * 1000;
>>
>>    INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,
>> &seltv), res, os::Bsd::clear_interrupted);
>> #else
>>    struct pollfd pfd;
>>
>>    pfd.fd = fd;
>>    pfd.events = POLLIN | POLLERR;
>>
>>    INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res,
>> os::Bsd::clear_interrupted);
>> #endif
>>
>> In fact, if I remove the #if part and revert to the #else block.
>> Everything works again. I'm using OS X 10.5.6 on a 32bit Core Duo
>> MacBook.
>>
>> Thanks
>> Max
>>
>> On Jan 22, 2009, at 12:40 PM, Max (Weijun) Wang wrote:
>>
>>  It seems even the simplest networking code fails.
>>>
>>> $ cat ~/tmp/A.java
>>> class  A {
>>>  public static void main(String[] args) throws Exception {
>>>   new java.net.ServerSocket(10000).accept();
>>>  }
>>> }
>>>
>>> $ java A
>>> Exception in thread "main" java.net.SocketException: Invalid argument
>>>        at java.net.PlainSocketImpl.socketAccept(Native Method)
>>>        at
>>> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
>>> 364)
>>>        at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>>>        at java.net.ServerSocket.accept(ServerSocket.java:481)
>>>        at A.main(A.java:3)
>>>
>>> Don't know why. The problem comes from C function NET_Accept, which is
>>> mentioned in these files:
>>>
>>>  jdk/make/java/net/FILES_c.gmk
>>>     Include bsd_close.c when OS_VENDOR is FreeBSD
>>>  jdk/src/solaris/native/java/net/bsd_close.c
>>>     Defines a version of NET_Accept
>>>  jdk/src/solaris/native/java/net/net_util_md.h
>>>     Declares NET_Accept, using impl of bsd_close.c or JVM_Accept
>>> depending on defined(__FreeBSD__)
>>>
>>> I'm not familiar with BSD C coding. Anyway on Mac OS_VENDOR is Apple.
>>>
>>> Max
>>>
>>> On Dec 20, 2008, at 8:26 AM, Michael Franz wrote:
>>>
>>>  Hi,
>>>>
>>>> I am running NetBeans on OS X using OpenJDK 7.  This uses the X11
>>>> implementation as there is no native Cocoa/Carbon Swing
>>>> implementation.  There are a few quirks that I would like to
>>>> mention, maybe someone can indicate what part of the code these
>>>> issue are in.
>>>>
>>>> 1.  Menus - the cursor is sometimes 1 line item below what is
>>>> highlighted
>>>> 2.  Dual display - opening  new dialogs are centered between the
>>>> displays (not the current display netbeans is in).
>>>> 3. The log file has many of these exceptions:
>>>> java.net.SocketException: Invalid argument
>>>>      at java.net.PlainSocketImpl.socketAccept(Native Method)
>>>>      at
>>>> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
>>>> 364)
>>>>      at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>>>>      at java.net.ServerSocket.accept(ServerSocket.java:481)
>>>>      at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010)
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090122/525025af/attachment.html 

From Weijun.Wang at Sun.COM  Thu Jan 22 04:18:02 2009
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Thu, 22 Jan 2009 20:18:02 +0800
Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display
In-Reply-To: <fee4d890901220359i35c4d0a8le658273770246231@mail.gmail.com>
References: <fee4d890812191626i22ff982dra1740b6eeb082784@mail.gmail.com>
	<5294BFC6-8690-4894-A694-E79E8A3D8867@sun.com>
	<7AACCE5C-19BF-46D2-81A1-70B76709FBCD@sun.com>
	<2831F9FC-44B1-4581-AC89-E21717725CAE@sun.com>
	<fee4d890901220359i35c4d0a8le658273770246231@mail.gmail.com>
Message-ID: <ED23BE95-4288-4405-A95E-575D8E78BA7B@Sun.COM>

Hi Michael

Oh, I didn't know you've already solved it. I only notice this thread  
because JSN colleague Brad's name shows up somewhere.

Max

On Jan 22, 2009, at 7:59 PM, Michael Franz wrote:

> Max,
>
> Did you see this thread? http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000229.html
>
> Michael
>
> On Thu, Jan 22, 2009 at 1:20 AM, Max (Weijun) Wang <Weijun.Wang at sun.com 
> > wrote:
> The original #ifdef block has not taken care of timeout == -1. The  
> following codes work:
>
>    if (timeout > 0) {
>
>        seltv.tv_sec = timeout / 1000;
>        seltv.tv_usec = (timeout % 1000) * 1000;
>
>        INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,  
> &seltv), res, os::Bsd::clear_interrupted);
>    } else {
>        INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,  
> NULL), res, os::Bsd::clear_interrupted);
>    }
>
> Max
>
>
> On Jan 22, 2009, at 1:52 PM, Max (Weijun) Wang wrote:
>
> Sorry, my previous analysis is wrong. The problem seems to be in
> NET_timeout.
>
> I noticed some lines in hotspot/src/os/bsd/vm/hpi_bsd.hpp
> http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/file/4244db6cd9a9/src/os/bsd/vm/hpi_bsd.hpp
>
> #ifdef __APPLE__
>    // XXXDARWIN: poll() appears non-interruptable on Leopard:
> Thread.interrupt() failed to
>    // cause interrupt. Does poll work at all on Tiger? Needs
> investigation.
>    fd_set fdset;
>    struct timeval seltv;
>
>    FD_ZERO(&fdset);
>    FD_SET(fd, &fdset);
>
>    seltv.tv_sec = timeout / 1000;
>    seltv.tv_usec = (timeout % 1000) * 1000;
>
>    INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,
> &seltv), res, os::Bsd::clear_interrupted);
> #else
>    struct pollfd pfd;
>
>    pfd.fd = fd;
>    pfd.events = POLLIN | POLLERR;
>
>    INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res,
> os::Bsd::clear_interrupted);
> #endif
>
> In fact, if I remove the #if part and revert to the #else block.
> Everything works again. I'm using OS X 10.5.6 on a 32bit Core Duo
> MacBook.
>
> Thanks
> Max
>
> On Jan 22, 2009, at 12:40 PM, Max (Weijun) Wang wrote:
>
> It seems even the simplest networking code fails.
>
> $ cat ~/tmp/A.java
> class  A {
>  public static void main(String[] args) throws Exception {
>   new java.net.ServerSocket(10000).accept();
>  }
> }
>
> $ java A
> Exception in thread "main" java.net.SocketException: Invalid argument
>        at java.net.PlainSocketImpl.socketAccept(Native Method)
>        at
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
> 364)
>        at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>        at java.net.ServerSocket.accept(ServerSocket.java:481)
>        at A.main(A.java:3)
>
> Don't know why. The problem comes from C function NET_Accept, which is
> mentioned in these files:
>
>  jdk/make/java/net/FILES_c.gmk
>     Include bsd_close.c when OS_VENDOR is FreeBSD
>  jdk/src/solaris/native/java/net/bsd_close.c
>     Defines a version of NET_Accept
>  jdk/src/solaris/native/java/net/net_util_md.h
>     Declares NET_Accept, using impl of bsd_close.c or JVM_Accept
> depending on defined(__FreeBSD__)
>
> I'm not familiar with BSD C coding. Anyway on Mac OS_VENDOR is Apple.
>
> Max
>
> On Dec 20, 2008, at 8:26 AM, Michael Franz wrote:
>
> Hi,
>
> I am running NetBeans on OS X using OpenJDK 7.  This uses the X11
> implementation as there is no native Cocoa/Carbon Swing
> implementation.  There are a few quirks that I would like to
> mention, maybe someone can indicate what part of the code these
> issue are in.
>
> 1.  Menus - the cursor is sometimes 1 line item below what is
> highlighted
> 2.  Dual display - opening  new dialogs are centered between the
> displays (not the current display netbeans is in).
> 3. The log file has many of these exceptions:
> java.net.SocketException: Invalid argument
>      at java.net.PlainSocketImpl.socketAccept(Native Method)
>      at
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
> 364)
>      at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>      at java.net.ServerSocket.accept(ServerSocket.java:481)
>      at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010)
>
>
> Michael
>
>
>
>
>
>
>



From kurt at intricatesoftware.com  Thu Jan 22 08:43:37 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Thu, 22 Jan 2009 16:43:37 +0000
Subject: hg: bsd-port/bsd-port/jdk: Remove OpenBSD special case includes for
	inttypes.h. OpenBSD
Message-ID: <20090122164403.2A2B0DDCC@hg.openjdk.java.net>

Changeset: ccc35adc361f
Author:    kurt
Date:      2009-01-22 11:40 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/ccc35adc361f

Remove OpenBSD special case includes for inttypes.h. OpenBSD
has C99 stdint.h for years now. Also add a missing stdint.h
include to fix debug build.

! src/share/native/com/sun/java/util/jar/pack/main.cpp
! src/share/native/sun/awt/medialib/mlib_types.h
! src/solaris/native/sun/java2d/j2d_md.h



From mvfranz at gmail.com  Thu Jan 22 16:03:08 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Thu, 22 Jan 2009 19:03:08 -0500
Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display
In-Reply-To: <ED23BE95-4288-4405-A95E-575D8E78BA7B@Sun.COM>
References: <fee4d890812191626i22ff982dra1740b6eeb082784@mail.gmail.com>
	<5294BFC6-8690-4894-A694-E79E8A3D8867@sun.com>
	<7AACCE5C-19BF-46D2-81A1-70B76709FBCD@sun.com>
	<2831F9FC-44B1-4581-AC89-E21717725CAE@sun.com>
	<fee4d890901220359i35c4d0a8le658273770246231@mail.gmail.com>
	<ED23BE95-4288-4405-A95E-575D8E78BA7B@Sun.COM>
Message-ID: <fee4d890901221603y3c45e0e9i33dd31d5711bced8@mail.gmail.com>

Max,

I found the same things that you did.  I have not had time to investigate
(properly) whether the comments are valid or not.  So, the change has not
been committed.  If you have the time to test we could get these changes
into the repo.

Michael

On Thu, Jan 22, 2009 at 7:18 AM, Max (Weijun) Wang <Weijun.Wang at sun.com>wrote:

> Hi Michael
>
> Oh, I didn't know you've already solved it. I only notice this thread
> because JSN colleague Brad's name shows up somewhere.
>
> Max
>
>
> On Jan 22, 2009, at 7:59 PM, Michael Franz wrote:
>
>  Max,
>>
>> Did you see this thread?
>> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000229.html
>>
>> Michael
>>
>> On Thu, Jan 22, 2009 at 1:20 AM, Max (Weijun) Wang <Weijun.Wang at sun.com>
>> wrote:
>> The original #ifdef block has not taken care of timeout == -1. The
>> following codes work:
>>
>>   if (timeout > 0) {
>>
>>       seltv.tv_sec = timeout / 1000;
>>       seltv.tv_usec = (timeout % 1000) * 1000;
>>
>>       INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL, &seltv),
>> res, os::Bsd::clear_interrupted);
>>   } else {
>>       INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL, NULL),
>> res, os::Bsd::clear_interrupted);
>>   }
>>
>> Max
>>
>>
>> On Jan 22, 2009, at 1:52 PM, Max (Weijun) Wang wrote:
>>
>> Sorry, my previous analysis is wrong. The problem seems to be in
>> NET_timeout.
>>
>> I noticed some lines in hotspot/src/os/bsd/vm/hpi_bsd.hpp
>>
>> http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/file/4244db6cd9a9/src/os/bsd/vm/hpi_bsd.hpp
>>
>> #ifdef __APPLE__
>>   // XXXDARWIN: poll() appears non-interruptable on Leopard:
>> Thread.interrupt() failed to
>>   // cause interrupt. Does poll work at all on Tiger? Needs
>> investigation.
>>   fd_set fdset;
>>   struct timeval seltv;
>>
>>   FD_ZERO(&fdset);
>>   FD_SET(fd, &fdset);
>>
>>   seltv.tv_sec = timeout / 1000;
>>   seltv.tv_usec = (timeout % 1000) * 1000;
>>
>>   INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,
>> &seltv), res, os::Bsd::clear_interrupted);
>> #else
>>   struct pollfd pfd;
>>
>>   pfd.fd = fd;
>>   pfd.events = POLLIN | POLLERR;
>>
>>   INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res,
>> os::Bsd::clear_interrupted);
>> #endif
>>
>> In fact, if I remove the #if part and revert to the #else block.
>> Everything works again. I'm using OS X 10.5.6 on a 32bit Core Duo
>> MacBook.
>>
>> Thanks
>> Max
>>
>> On Jan 22, 2009, at 12:40 PM, Max (Weijun) Wang wrote:
>>
>> It seems even the simplest networking code fails.
>>
>> $ cat ~/tmp/A.java
>> class  A {
>>  public static void main(String[] args) throws Exception {
>>  new java.net.ServerSocket(10000).accept();
>>  }
>> }
>>
>> $ java A
>> Exception in thread "main" java.net.SocketException: Invalid argument
>>       at java.net.PlainSocketImpl.socketAccept(Native Method)
>>       at
>> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
>> 364)
>>       at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>>       at java.net.ServerSocket.accept(ServerSocket.java:481)
>>       at A.main(A.java:3)
>>
>> Don't know why. The problem comes from C function NET_Accept, which is
>> mentioned in these files:
>>
>>  jdk/make/java/net/FILES_c.gmk
>>    Include bsd_close.c when OS_VENDOR is FreeBSD
>>  jdk/src/solaris/native/java/net/bsd_close.c
>>    Defines a version of NET_Accept
>>  jdk/src/solaris/native/java/net/net_util_md.h
>>    Declares NET_Accept, using impl of bsd_close.c or JVM_Accept
>> depending on defined(__FreeBSD__)
>>
>> I'm not familiar with BSD C coding. Anyway on Mac OS_VENDOR is Apple.
>>
>> Max
>>
>> On Dec 20, 2008, at 8:26 AM, Michael Franz wrote:
>>
>> Hi,
>>
>> I am running NetBeans on OS X using OpenJDK 7.  This uses the X11
>> implementation as there is no native Cocoa/Carbon Swing
>> implementation.  There are a few quirks that I would like to
>> mention, maybe someone can indicate what part of the code these
>> issue are in.
>>
>> 1.  Menus - the cursor is sometimes 1 line item below what is
>> highlighted
>> 2.  Dual display - opening  new dialogs are centered between the
>> displays (not the current display netbeans is in).
>> 3. The log file has many of these exceptions:
>> java.net.SocketException: Invalid argument
>>     at java.net.PlainSocketImpl.socketAccept(Native Method)
>>     at
>> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
>> 364)
>>     at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>>     at java.net.ServerSocket.accept(ServerSocket.java:481)
>>     at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010)
>>
>>
>> Michael
>>
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090122/dd0ebb16/attachment.html 

From Weijun.Wang at Sun.COM  Thu Jan 22 16:20:18 2009
From: Weijun.Wang at Sun.COM (Max (Weijun) Wang)
Date: Fri, 23 Jan 2009 08:20:18 +0800
Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display
In-Reply-To: <fee4d890901221603y3c45e0e9i33dd31d5711bced8@mail.gmail.com>
References: <fee4d890812191626i22ff982dra1740b6eeb082784@mail.gmail.com>
	<5294BFC6-8690-4894-A694-E79E8A3D8867@sun.com>
	<7AACCE5C-19BF-46D2-81A1-70B76709FBCD@sun.com>
	<2831F9FC-44B1-4581-AC89-E21717725CAE@sun.com>
	<fee4d890901220359i35c4d0a8le658273770246231@mail.gmail.com>
	<ED23BE95-4288-4405-A95E-575D8E78BA7B@Sun.COM>
	<fee4d890901221603y3c45e0e9i33dd31d5711bced8@mail.gmail.com>
Message-ID: <034F4CC1-32BC-4CFD-AAB1-B3BB1006F534@Sun.COM>

Michael

The findings in the comments are almost identical to mine: Both the  
#else block (using poll) and #ifdef block (after fixing -1 timeout)  
work for me. I also don't understand why the #ifdef block was added  
from the beginning. That change was made by Landon at http://hg.bikemonkey.org/javasrc_1_6_jrl_darwin/rev/2dee67c0e1db 
.

My Macbook is a 32 bit Core Duo running 10.5.6. Perhaps poll does not  
work on other platforms? Say, 10.5.0, or 64 bit Core 2 Duo?

Also, [1] shows that bsd-port is to support all of FreeBSD, OpenBSD,  
NetBSD and MacOS X. We need to form a consortium to cover them as many  
as possible.

Thanks
Max

[1] http://mail.openjdk.java.net/pipermail/porters-dev/2008-July/000170.html

On Jan 23, 2009, at 8:03 AM, Michael Franz wrote:

> Max,
>
> I found the same things that you did.  I have not had time to  
> investigate (properly) whether the comments are valid or not.  So,  
> the change has not been committed.  If you have the time to test we  
> could get these changes into the repo.
>
> Michael
>
> On Thu, Jan 22, 2009 at 7:18 AM, Max (Weijun) Wang <Weijun.Wang at sun.com 
> > wrote:
> Hi Michael
>
> Oh, I didn't know you've already solved it. I only notice this  
> thread because JSN colleague Brad's name shows up somewhere.
>
> Max
>
>
> On Jan 22, 2009, at 7:59 PM, Michael Franz wrote:
>
> Max,
>
> Did you see this thread? http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-December/000229.html
>
> Michael
>
> On Thu, Jan 22, 2009 at 1:20 AM, Max (Weijun) Wang <Weijun.Wang at sun.com 
> > wrote:
> The original #ifdef block has not taken care of timeout == -1. The  
> following codes work:
>
>   if (timeout > 0) {
>
>       seltv.tv_sec = timeout / 1000;
>       seltv.tv_usec = (timeout % 1000) * 1000;
>
>       INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,  
> &seltv), res, os::Bsd::clear_interrupted);
>   } else {
>       INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,  
> NULL), res, os::Bsd::clear_interrupted);
>   }
>
> Max
>
>
> On Jan 22, 2009, at 1:52 PM, Max (Weijun) Wang wrote:
>
> Sorry, my previous analysis is wrong. The problem seems to be in
> NET_timeout.
>
> I noticed some lines in hotspot/src/os/bsd/vm/hpi_bsd.hpp
> http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/file/4244db6cd9a9/src/os/bsd/vm/hpi_bsd.hpp
>
> #ifdef __APPLE__
>   // XXXDARWIN: poll() appears non-interruptable on Leopard:
> Thread.interrupt() failed to
>   // cause interrupt. Does poll work at all on Tiger? Needs
> investigation.
>   fd_set fdset;
>   struct timeval seltv;
>
>   FD_ZERO(&fdset);
>   FD_SET(fd, &fdset);
>
>   seltv.tv_sec = timeout / 1000;
>   seltv.tv_usec = (timeout % 1000) * 1000;
>
>   INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL,
> &seltv), res, os::Bsd::clear_interrupted);
> #else
>   struct pollfd pfd;
>
>   pfd.fd = fd;
>   pfd.events = POLLIN | POLLERR;
>
>   INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res,
> os::Bsd::clear_interrupted);
> #endif
>
> In fact, if I remove the #if part and revert to the #else block.
> Everything works again. I'm using OS X 10.5.6 on a 32bit Core Duo
> MacBook.
>
> Thanks
> Max
>
> On Jan 22, 2009, at 12:40 PM, Max (Weijun) Wang wrote:
>
> It seems even the simplest networking code fails.
>
> $ cat ~/tmp/A.java
> class  A {
>  public static void main(String[] args) throws Exception {
>  new java.net.ServerSocket(10000).accept();
>  }
> }
>
> $ java A
> Exception in thread "main" java.net.SocketException: Invalid argument
>       at java.net.PlainSocketImpl.socketAccept(Native Method)
>       at
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
> 364)
>       at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>       at java.net.ServerSocket.accept(ServerSocket.java:481)
>       at A.main(A.java:3)
>
> Don't know why. The problem comes from C function NET_Accept, which is
> mentioned in these files:
>
>  jdk/make/java/net/FILES_c.gmk
>    Include bsd_close.c when OS_VENDOR is FreeBSD
>  jdk/src/solaris/native/java/net/bsd_close.c
>    Defines a version of NET_Accept
>  jdk/src/solaris/native/java/net/net_util_md.h
>    Declares NET_Accept, using impl of bsd_close.c or JVM_Accept
> depending on defined(__FreeBSD__)
>
> I'm not familiar with BSD C coding. Anyway on Mac OS_VENDOR is Apple.
>
> Max
>
> On Dec 20, 2008, at 8:26 AM, Michael Franz wrote:
>
> Hi,
>
> I am running NetBeans on OS X using OpenJDK 7.  This uses the X11
> implementation as there is no native Cocoa/Carbon Swing
> implementation.  There are a few quirks that I would like to
> mention, maybe someone can indicate what part of the code these
> issue are in.
>
> 1.  Menus - the cursor is sometimes 1 line item below what is
> highlighted
> 2.  Dual display - opening  new dialogs are centered between the
> displays (not the current display netbeans is in).
> 3. The log file has many of these exceptions:
> java.net.SocketException: Invalid argument
>     at java.net.PlainSocketImpl.socketAccept(Native Method)
>     at
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:
> 364)
>     at java.net.ServerSocket.implAccept(ServerSocket.java:513)
>     at java.net.ServerSocket.accept(ServerSocket.java:481)
>     at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010)
>
>
> Michael
>
>
>
>
>
>
>
>
>
>



From glewis at eyesbeyond.com  Thu Jan 22 18:52:49 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Fri, 23 Jan 2009 02:52:49 +0000
Subject: hg: bsd-port/bsd-port/hotspot: 2 new changesets
Message-ID: <20090123025253.609C9DE9E@hg.openjdk.java.net>

Changeset: 0273528e9e37
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-22 18:48 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/0273528e9e37

. Remove Mac OS X specific code which is currently reported as actually
  causing problems on Mac OS X (specifically Leopard).  This can be
  revived if someone sees problems on Tiger and is willing to clean it
  up.

! src/os/bsd/vm/hpi_bsd.hpp

Changeset: afd16fa8b690
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-22 18:51 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/afd16fa8b690

. Merging in changes from BSD repo.




From glewis at eyesbeyond.com  Thu Jan 22 21:55:15 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Fri, 23 Jan 2009 05:55:15 +0000
Subject: hg: bsd-port/bsd-port: 3 new changesets
Message-ID: <20090123055515.A03B7DF20@hg.openjdk.java.net>

Changeset: a395e3aac474
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/rev/a395e3aac474

Added tag jdk7-b43 for changeset 848e684279d2

! .hgtags

Changeset: 99846f001ca2
Author:    xdono
Date:      2009-01-22 14:41 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/rev/99846f001ca2

Added tag jdk7-b44 for changeset a395e3aac474

! .hgtags

Changeset: 6d0adb248b42
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-22 19:19 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/rev/6d0adb248b42

. Merging changes from main OpenJDK repository.




From glewis at eyesbeyond.com  Thu Jan 22 21:56:37 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Fri, 23 Jan 2009 05:56:37 +0000
Subject: hg: bsd-port/bsd-port/corba: 3 new changesets
Message-ID: <20090123055640.7BAA3DF50@hg.openjdk.java.net>

Changeset: 9803dac72540
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/corba/rev/9803dac72540

Added tag jdk7-b43 for changeset 9cd740d48a48

! .hgtags

Changeset: 68814aa5b44b
Author:    xdono
Date:      2009-01-22 14:41 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/corba/rev/68814aa5b44b

Added tag jdk7-b44 for changeset 9803dac72540

! .hgtags

Changeset: c15ebbe94f71
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-22 19:21 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/corba/rev/c15ebbe94f71

. Merge changes from main OpenJDK repository.




From glewis at eyesbeyond.com  Thu Jan 22 21:58:06 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Fri, 23 Jan 2009 05:58:06 +0000
Subject: hg: bsd-port/bsd-port/hotspot: 3 new changesets
Message-ID: <20090123055811.D5770DF55@hg.openjdk.java.net>

Changeset: 809e899c638b
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/809e899c638b

Added tag jdk7-b43 for changeset fc6a5ae3fef5

! .hgtags

Changeset: 945bf7540697
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/945bf7540697

Added tag jdk7-b44 for changeset 809e899c638b

! .hgtags

Changeset: 0c813371a392
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-22 19:22 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/0c813371a392

. Merge changes from main OpenJDK repository.




From glewis at eyesbeyond.com  Thu Jan 22 21:59:35 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Fri, 23 Jan 2009 05:59:35 +0000
Subject: hg: bsd-port/bsd-port/jaxp: 3 new changesets
Message-ID: <20090123055939.E7418DF5F@hg.openjdk.java.net>

Changeset: b203df0741af
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jaxp/rev/b203df0741af

Added tag jdk7-b43 for changeset 96fe28d4a913

! .hgtags

Changeset: 0f113667880d
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jaxp/rev/0f113667880d

Added tag jdk7-b44 for changeset b203df0741af

! .hgtags

Changeset: 6c932ce8ffd1
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-22 19:22 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jaxp/rev/6c932ce8ffd1

. Merge changes from main OpenJDK repository.




From glewis at eyesbeyond.com  Thu Jan 22 22:01:03 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Fri, 23 Jan 2009 06:01:03 +0000
Subject: hg: bsd-port/bsd-port/jaxws: 3 new changesets
Message-ID: <20090123060108.09CD6DF64@hg.openjdk.java.net>

Changeset: 344485a03674
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jaxws/rev/344485a03674

Added tag jdk7-b43 for changeset 1ad2f51564db

! .hgtags

Changeset: dea7753d7139
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jaxws/rev/dea7753d7139

Added tag jdk7-b44 for changeset 344485a03674

! .hgtags

Changeset: 20b632ea9176
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-22 19:23 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jaxws/rev/20b632ea9176

. Merge changes from main OpenJDK repository.




From glewis at eyesbeyond.com  Thu Jan 22 22:02:36 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Fri, 23 Jan 2009 06:02:36 +0000
Subject: hg: bsd-port/bsd-port/jdk: 19 new changesets
Message-ID: <20090123060614.B1186DF75@hg.openjdk.java.net>

Changeset: 8dcc06d43798
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/8dcc06d43798

Added tag jdk7-b43 for changeset 50c67678b0d1

! .hgtags

Changeset: 57dc40ece164
Author:    sherman
Date:      2008-12-17 22:50 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/57dc40ece164

6496274: jar seems to use more CPU than it should
Summary: boost jar creating performance especially for the large jar file
Reviewed-by: martin

! src/share/classes/sun/tools/jar/Main.java

Changeset: 85fe3cd9d6f9
Author:    wetmore
Date:      2008-12-19 10:35 +0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/85fe3cd9d6f9

6750401: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes,with PCKS11 provider
Summary: This is the JSSE portion of the fix. Main part is in PKCS11.
Reviewed-by: valeriep, xuelei

! src/share/classes/sun/security/ssl/CipherBox.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java

Changeset: 850d381fa9aa
Author:    tbell
Date:      2008-12-19 22:07 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/850d381fa9aa

Merge


Changeset: 3d09cc6c4ea9
Author:    alanb
Date:      2008-12-22 19:28 +0000
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3d09cc6c4ea9

6787009: (attach) Stub injection potentially unsafe on windows-x64
Reviewed-by: mchung

! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c

Changeset: 37a9442e3203
Author:    tbell
Date:      2009-01-09 21:54 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/37a9442e3203

Merge


Changeset: 0bd360988b3a
Author:    thurka
Date:      2009-01-07 14:06 +0100
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/0bd360988b3a

6790467: Add test for setInterval() for local MonitoredHost and local MonitoredVm
Summary: test for MonitoredHost.setInterval() and MonitoredVm.setInterval() added
Reviewed-by: swamyv

+ test/sun/jvmstat/monitor/MonitoredVm/CR6672135.java

Changeset: ff572b4f1ca4
Author:    martin
Date:      2009-01-07 11:50 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/ff572b4f1ca4

6788196: (porting) Bounds checks in io_util.c rely on undefined behaviour
Reviewed-by: alanb
Contributed-by: gbenson at redhat.com

! src/share/native/java/io/io_util.c
! test/java/io/readBytes/ReadBytesBounds.java

Changeset: 0272e442cc5b
Author:    martin
Date:      2009-01-08 14:07 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/0272e442cc5b

6791458: FileInputStream/RandomAccessFile.read leaks memory if invoked on closed stream with len > 8k
Reviewed-by: alanb
Contributed-by: jeremymanson at google.com

! src/share/native/java/io/io_util.c
+ test/java/io/readBytes/MemoryLeak.java

Changeset: f6c105e60186
Author:    bpatel
Date:      2009-01-07 16:39 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/f6c105e60186

6790217: Javadoc HTML WCAG 2.0 accessibility issues in jdk docs makefile - Bold tags should be strong
Reviewed-by: jjg

! make/docs/Makefile

Changeset: 71a6cd33d365
Author:    bpatel
Date:      2009-01-08 14:17 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/71a6cd33d365

Merge


Changeset: f5062c0ae8d5
Author:    bpatel
Date:      2009-01-08 15:10 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/f5062c0ae8d5

Merge


Changeset: 961ea5a46a0c
Author:    martin
Date:      2009-01-09 16:48 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/961ea5a46a0c

6792066: src/share/native/java/io/io_util.c clean-ups
Reviewed-by: alanb

! src/share/native/java/io/io_util.c
! src/share/native/java/io/io_util.h

Changeset: 5c39d920b488
Author:    tbell
Date:      2009-01-09 22:01 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/5c39d920b488

Merge


Changeset: 4dab1a24dca2
Author:    tbell
Date:      2009-01-16 10:37 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/4dab1a24dca2

Merge


Changeset: 6dce6ac0929e
Author:    tbell
Date:      2009-01-14 21:35 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/6dce6ac0929e

6754862: jdk/src/windows/bin/java_md.c: hardcoded reference to msvcr71.dll
6779412: VS2008 errors compiling jdk sources
Summary: Update Makefiles to tolerate newer Visual Studio releases and runtimes.
Reviewed-by: ohair

! make/com/sun/java/pack/Makefile
! make/common/Defs-windows.gmk
! make/common/Library.gmk
! make/common/Program.gmk
! make/common/shared/Compiler-msvc.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk
! make/java/main/java/Makefile
! make/java/main/javaw/Makefile
! make/java/redist/Makefile
! src/share/bin/main.c
! src/windows/bin/java_md.c

Changeset: d8eb2738db6b
Author:    xdono
Date:      2009-01-20 09:42 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/d8eb2738db6b

Merge

- src/share/classes/sun/nio/cs/IBM437.java
- src/share/classes/sun/nio/cs/IBM737.java
- src/share/classes/sun/nio/cs/IBM775.java
- src/share/classes/sun/nio/cs/IBM850.java
- src/share/classes/sun/nio/cs/IBM852.java
- src/share/classes/sun/nio/cs/IBM855.java
- src/share/classes/sun/nio/cs/IBM857.java
- src/share/classes/sun/nio/cs/IBM858.java
- src/share/classes/sun/nio/cs/IBM862.java
- src/share/classes/sun/nio/cs/IBM866.java
- src/share/classes/sun/nio/cs/IBM874.java
- src/share/classes/sun/nio/cs/ISO_8859_13.java
- src/share/classes/sun/nio/cs/ISO_8859_15.java
- src/share/classes/sun/nio/cs/ISO_8859_2.java
- src/share/classes/sun/nio/cs/ISO_8859_4.java
- src/share/classes/sun/nio/cs/ISO_8859_5.java
- src/share/classes/sun/nio/cs/ISO_8859_7.java
- src/share/classes/sun/nio/cs/ISO_8859_9.java
- src/share/classes/sun/nio/cs/KOI8_R.java
- src/share/classes/sun/nio/cs/KOI8_U.java
- src/share/classes/sun/nio/cs/MS1250.java
- src/share/classes/sun/nio/cs/MS1251.java
- src/share/classes/sun/nio/cs/MS1252.java
- src/share/classes/sun/nio/cs/MS1253.java
- src/share/classes/sun/nio/cs/MS1254.java
- src/share/classes/sun/nio/cs/MS1257.java
- src/share/classes/sun/nio/cs/ext/IBM037.java
- src/share/classes/sun/nio/cs/ext/IBM1006.java
- src/share/classes/sun/nio/cs/ext/IBM1025.java
- src/share/classes/sun/nio/cs/ext/IBM1026.java
- src/share/classes/sun/nio/cs/ext/IBM1046.java
- src/share/classes/sun/nio/cs/ext/IBM1047.java
- src/share/classes/sun/nio/cs/ext/IBM1097.java
- src/share/classes/sun/nio/cs/ext/IBM1098.java
- src/share/classes/sun/nio/cs/ext/IBM1112.java
- src/share/classes/sun/nio/cs/ext/IBM1122.java
- src/share/classes/sun/nio/cs/ext/IBM1123.java
- src/share/classes/sun/nio/cs/ext/IBM1124.java
- src/share/classes/sun/nio/cs/ext/IBM1140.java
- src/share/classes/sun/nio/cs/ext/IBM1141.java
- src/share/classes/sun/nio/cs/ext/IBM1142.java
- src/share/classes/sun/nio/cs/ext/IBM1143.java
- src/share/classes/sun/nio/cs/ext/IBM1144.java
- src/share/classes/sun/nio/cs/ext/IBM1145.java
- src/share/classes/sun/nio/cs/ext/IBM1146.java
- src/share/classes/sun/nio/cs/ext/IBM1147.java
- src/share/classes/sun/nio/cs/ext/IBM1148.java
- src/share/classes/sun/nio/cs/ext/IBM1149.java
- src/share/classes/sun/nio/cs/ext/IBM273.java
- src/share/classes/sun/nio/cs/ext/IBM277.java
- src/share/classes/sun/nio/cs/ext/IBM278.java
- src/share/classes/sun/nio/cs/ext/IBM280.java
- src/share/classes/sun/nio/cs/ext/IBM284.java
- src/share/classes/sun/nio/cs/ext/IBM285.java
- src/share/classes/sun/nio/cs/ext/IBM297.java
- src/share/classes/sun/nio/cs/ext/IBM420.java
- src/share/classes/sun/nio/cs/ext/IBM424.java
- src/share/classes/sun/nio/cs/ext/IBM500.java
- src/share/classes/sun/nio/cs/ext/IBM838.java
- src/share/classes/sun/nio/cs/ext/IBM856.java
- src/share/classes/sun/nio/cs/ext/IBM860.java
- src/share/classes/sun/nio/cs/ext/IBM861.java
- src/share/classes/sun/nio/cs/ext/IBM863.java
- src/share/classes/sun/nio/cs/ext/IBM864.java
- src/share/classes/sun/nio/cs/ext/IBM865.java
- src/share/classes/sun/nio/cs/ext/IBM868.java
- src/share/classes/sun/nio/cs/ext/IBM869.java
- src/share/classes/sun/nio/cs/ext/IBM870.java
- src/share/classes/sun/nio/cs/ext/IBM871.java
- src/share/classes/sun/nio/cs/ext/IBM875.java
- src/share/classes/sun/nio/cs/ext/IBM918.java
- src/share/classes/sun/nio/cs/ext/IBM921.java
- src/share/classes/sun/nio/cs/ext/IBM922.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_11.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_3.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_6.java
- src/share/classes/sun/nio/cs/ext/ISO_8859_8.java
- src/share/classes/sun/nio/cs/ext/MS1255.java
- src/share/classes/sun/nio/cs/ext/MS1256.java
- src/share/classes/sun/nio/cs/ext/MS1258.java
- src/share/classes/sun/nio/cs/ext/MS874.java
- src/share/classes/sun/nio/cs/ext/MacArabic.java
- src/share/classes/sun/nio/cs/ext/MacCentralEurope.java
- src/share/classes/sun/nio/cs/ext/MacCroatian.java
- src/share/classes/sun/nio/cs/ext/MacCyrillic.java
- src/share/classes/sun/nio/cs/ext/MacDingbat.java
- src/share/classes/sun/nio/cs/ext/MacGreek.java
- src/share/classes/sun/nio/cs/ext/MacHebrew.java
- src/share/classes/sun/nio/cs/ext/MacIceland.java
- src/share/classes/sun/nio/cs/ext/MacRoman.java
- src/share/classes/sun/nio/cs/ext/MacRomania.java
- src/share/classes/sun/nio/cs/ext/MacSymbol.java
- src/share/classes/sun/nio/cs/ext/MacThai.java
- src/share/classes/sun/nio/cs/ext/MacTurkish.java
- src/share/classes/sun/nio/cs/ext/MacUkraine.java
- src/share/classes/sun/nio/cs/ext/TIS_620.java

Changeset: 527b426497a2
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/527b426497a2

Added tag jdk7-b44 for changeset d8eb2738db6b

! .hgtags

Changeset: c969e34397f6
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-22 19:32 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/c969e34397f6

. Merge changes from main OpenJDK repository.

! make/com/sun/java/pack/Makefile
! make/common/Program.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk
! make/docs/Makefile
! make/java/redist/Makefile
! src/share/classes/sun/tools/jar/Main.java
! src/share/native/java/io/io_util.h



From glewis at eyesbeyond.com  Thu Jan 22 22:07:40 2009
From: glewis at eyesbeyond.com (glewis at eyesbeyond.com)
Date: Fri, 23 Jan 2009 06:07:40 +0000
Subject: hg: bsd-port/bsd-port/langtools: 11 new changesets
Message-ID: <20090123060758.04CA1DF7A@hg.openjdk.java.net>

Changeset: 05b47447cbcf
Author:    xdono
Date:      2009-01-15 11:46 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/05b47447cbcf

Added tag jdk7-b43 for changeset e2f8f6daee9d

! .hgtags

Changeset: 7a595d92e252
Author:    jjg
Date:      2009-01-07 14:48 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/7a595d92e252

6512707: "incompatible types" after (unrelated) annotation processing
Reviewed-by: darcy
Contributed-by: prunge at velocitynet.com.au

! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java
+ test/tools/javac/processing/6512707/T6512707.java
+ test/tools/javac/processing/6512707/TestAnnotation.java
+ test/tools/javac/processing/6512707/TestEnum.java

Changeset: 47a62d8d98b4
Author:    bpatel
Date:      2009-01-08 16:26 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/47a62d8d98b4

6786028: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - Bold tags should be strong
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java
! test/com/sun/javadoc/AccessAsciiArt/AccessAsciiArt.java
! test/com/sun/javadoc/AuthorDD/AuthorDD.java
! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java
! test/com/sun/javadoc/testClassTree/TestClassTree.java
! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java
! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java
! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java
! test/com/sun/javadoc/testHeadings/TestHeadings.java
! test/com/sun/javadoc/testHelpOption/TestHelpOption.java
! test/com/sun/javadoc/testHref/TestHref.java
+ test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java
+ test/com/sun/javadoc/testHtmlStrongTag/pkg1/C1.java
+ test/com/sun/javadoc/testHtmlStrongTag/pkg2/C2.java
! test/com/sun/javadoc/testIndex/TestIndex.java
! test/com/sun/javadoc/testInterface/TestInterface.java
! test/com/sun/javadoc/testJavascript/TestJavascript.java
! test/com/sun/javadoc/testLinkOption/TestLinkOption.java
! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java
! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java
! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java
! test/com/sun/javadoc/testNavagation/TestNavagation.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java
! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java
! test/com/sun/javadoc/testPackagePage/TestPackagePage.java
! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java
! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java
! test/com/sun/javadoc/testSerializedForm/TestSerializedForm.java
! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java
! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java
! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java
! test/com/sun/javadoc/testValueTag/TestValueTag.java

Changeset: dbe9e82f9d25
Author:    bpatel
Date:      2009-01-08 16:34 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/dbe9e82f9d25

Merge

! test/com/sun/javadoc/AuthorDD/AuthorDD.java

Changeset: 905e151a185a
Author:    mcimadamore
Date:      2009-01-13 13:27 +0000
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/905e151a185a

6765045: Remove rawtypes warnings from langtools
Summary: Removed all occurrences of rawtypes warnings from langtools
Reviewed-by: jjg, bpatel

! make/build.properties
! src/share/classes/com/sun/source/util/Trees.java
! src/share/classes/com/sun/tools/apt/comp/Apt.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java
! src/share/classes/com/sun/tools/javac/Main.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java
! src/share/classes/com/sun/tools/javac/util/Context.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javac/util/Pair.java
! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java
! src/share/classes/com/sun/tools/javah/Gen.java
! src/share/classes/com/sun/tools/javah/LLNI.java
! src/share/classes/com/sun/tools/javah/TypeSignature.java
! src/share/classes/sun/tools/javap/FieldData.java
! src/share/classes/sun/tools/javap/JavapPrinter.java
! src/share/classes/sun/tools/javap/MethodData.java

Changeset: d57378c34fdb
Author:    mcimadamore
Date:      2009-01-13 13:28 +0000
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/d57378c34fdb

6665356: Cast not allowed when both qualifying type and inner class are parameterized
Summary: Fixed parser and cats conversion in order to allow cast between generic inner classes
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/cast/6665356/T6665356.java
+ test/tools/javac/cast/6665356/T6665356.out
+ test/tools/javac/generics/rare/6665356/T6665356.java
+ test/tools/javac/generics/rare/6665356/T6665356.out

Changeset: 09eb1acc9610
Author:    mcimadamore
Date:      2009-01-13 13:28 +0000
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/09eb1acc9610

6723444: javac fails to substitute type variables into a constructor's throws clause
Summary: Added constructor's actual type info to NewClass AST node
Reviewed-by: jjg
Contributed-by: mark at twistedbanana.demon.co.uk

! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
+ test/tools/javac/generics/6723444/T6723444.java
+ test/tools/javac/generics/6723444/T6723444.out

Changeset: e157bd68dfc5
Author:    mcimadamore
Date:      2009-01-13 13:31 +0000
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/e157bd68dfc5

6558559: Extra "unchecked" diagnostic
Summary: Fixed Types.sideCast in order to suppress redundant unchecked warnings
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/6558559/T6558559a.java
+ test/tools/javac/cast/6558559/T6558559b.java

Changeset: 28f0b10d6c1a
Author:    tbell
Date:      2009-01-16 10:38 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/28f0b10d6c1a

Merge


Changeset: 30db5e0aaf83
Author:    xdono
Date:      2009-01-22 14:42 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/30db5e0aaf83

Added tag jdk7-b44 for changeset 28f0b10d6c1a

! .hgtags

Changeset: dbcb077bd200
Author:    glewis at misty.eyesbeyond.com
Date:      2009-01-22 19:24 -0800
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/dbcb077bd200

. Merge changes from main OpenJDK repository.




From kurt at intricatesoftware.com  Fri Jan 23 06:38:09 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Fri, 23 Jan 2009 14:38:09 +0000
Subject: hg: bsd-port/bsd-port/jdk: Remove duplicate font path from
	fullBSDFontPath.
Message-ID: <20090123143821.2CAC2DFCF@hg.openjdk.java.net>

Changeset: dab576664377
Author:    kurt
Date:      2009-01-23 09:36 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/dab576664377

Remove duplicate font path from fullBSDFontPath.

! src/solaris/native/sun/awt/fontpath.c



From christos at zoulas.com  Fri Jan 23 08:28:55 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 23 Jan 2009 11:28:55 -0500
Subject: I would like to apply the following changes
Message-ID: <20090123162855.C07915654F@rebar.astron.com>

Hello,

I would like to apply the following changes:

1. NetBSD uses statfvs
2. passing possibly negative values to isdigit is undefined behavior:
   http://www.opengroup.org/onlinepubs/009695399/functions/isdigit.html
3. passing possibly negative values to isspace is undefined behavior:
   http://www.opengroup.org/onlinepubs/009695399/functions/isspace.html
4. last is possibly uninitialized.
5. recvfrom argument should be socklen_t not int:
   http://www.opengroup.org/onlinepubs/007908775/xns/recvfrom.html
6. NetBSD uses <net/if_ether.h>

1, 6 are NetBSD specific, the rest should be applied to everyone.

Ok to commit?

Thanks,

christos

diff -r fc30e7f4b9b3 src/solaris/native/java/io/UnixFileSystem_md.c
--- a/src/solaris/native/java/io/UnixFileSystem_md.c	Fri Jan 16 11:24:18 2009 -0500
+++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Mon Jan 22 16:25:36 2009 -0500
@@ -47,6 +47,9 @@
 #define readdir64 readdir
 #define stat64 stat
 #endif
+#ifdef __NetBSD__
+#define statfs statvfs
+#endif
 
 /* -- Field IDs -- */
 
diff -r fc30e7f4b9b3 src/solaris/native/java/lang/UNIXProcess_md.c
--- a/src/solaris/native/java/lang/UNIXProcess_md.c	Fri Jan 16 11:24:18 2009 -0500
+++ b/src/solaris/native/java/lang/UNIXProcess_md.c	Mon Jan 22 16:25:36 2009 -0500
@@ -377,7 +377,7 @@
      */
     while ((dirp = readdir(dp)) != NULL) {
         int fd;
-        if (isdigit(dirp->d_name[0]) &&
+        if (isdigit((unsigned char)dirp->d_name[0]) &&
             (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd + 2)
             close(fd);
     }
diff -r fc30e7f4b9b3 src/solaris/native/java/net/Inet4AddressImpl.c
--- a/src/solaris/native/java/net/Inet4AddressImpl.c	Fri Jan 16 11:24:18 2009 -0500
+++ b/src/solaris/native/java/net/Inet4AddressImpl.c	Mon Jan 22 16:25:36 2009 -0500
@@ -155,7 +155,7 @@
      * Workaround for Solaris bug 4160367 - if a hostname contains a
      * white space then 0.0.0.0 is returned
      */
-    if (isspace(hostname[0])) {
+    if (isspace((unsigned char)hostname[0])) {
 	JNU_ThrowByName(env, JNU_JAVANETPKG "UnknownHostException",
 			(char *)hostname);
 	JNU_ReleaseStringPlatformChars(env, host, hostname);
@@ -172,7 +172,7 @@
 	return NULL;
     } else {
 	int i = 0;
-	struct addrinfo *itr, *last, *iterator = res;
+	struct addrinfo *itr, *last = NULL, *iterator = res;
 	while (iterator != NULL) {
 	    int skip = 0;
 	    itr = resNew;
@@ -603,7 +603,8 @@
 ping4(JNIEnv *env, jint fd, struct sockaddr_in* him, jint timeout,
       struct sockaddr_in* netif, jint ttl) {
     jint size;
-    jint n, len, hlen1, icmplen;
+    jint n, hlen1, icmplen;
+    socklen_t len;
     char sendbuf[1500];
     char recvbuf[1500];
     struct icmp *icmp;
diff -r fc30e7f4b9b3 src/solaris/native/java/net/NetworkInterface.c
--- a/src/solaris/native/java/net/NetworkInterface.c	Fri Jan 16 11:24:18 2009 -0500
+++ b/src/solaris/native/java/net/NetworkInterface.c	Mon Jan 22 16:25:36 2009 -0500
@@ -55,6 +55,8 @@
 #include <net/if_var.h>
 #elif defined(__OpenBSD__)
 #include <netinet/if_ether.h>
+#elif defined(__NetBSD__)
+#include <net/if_ether.h>
 #endif
 #include <net/if_dl.h>
 #include <netinet/in_var.h>


From gnu_andrew at member.fsf.org  Fri Jan 23 09:24:34 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 23 Jan 2009 17:24:34 +0000
Subject: I would like to apply the following changes
In-Reply-To: <20090123162855.C07915654F@rebar.astron.com>
References: <20090123162855.C07915654F@rebar.astron.com>
Message-ID: <17c6771e0901230924p79d2d540xd0ff66516754e095@mail.gmail.com>

2009/1/23 Christos Zoulas <christos at zoulas.com>:
> Hello,
>
> I would like to apply the following changes:
>
> 1. NetBSD uses statfvs
> 2. passing possibly negative values to isdigit is undefined behavior:
>   http://www.opengroup.org/onlinepubs/009695399/functions/isdigit.html
> 3. passing possibly negative values to isspace is undefined behavior:
>   http://www.opengroup.org/onlinepubs/009695399/functions/isspace.html
> 4. last is possibly uninitialized.
> 5. recvfrom argument should be socklen_t not int:
>   http://www.opengroup.org/onlinepubs/007908775/xns/recvfrom.html
> 6. NetBSD uses <net/if_ether.h>
>
> 1, 6 are NetBSD specific, the rest should be applied to everyone.

Are 2-5 general enough they should actually be sent to the main OpenJDK7 tree?
-- 
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 23 10:38:11 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Fri, 23 Jan 2009 13:38:11 -0500
Subject: I would like to apply the following changes
In-Reply-To: <20090123162855.C07915654F@rebar.astron.com>
References: <20090123162855.C07915654F@rebar.astron.com>
Message-ID: <497A0E93.9080106@intricatesoftware.com>

Hi Christos,

Sure these are fine.

Andrew has a good point. 2-5 should be submitted as bug reports
to the main tree.

Thanks,
-Kurt

Christos Zoulas wrote:
> Hello,
> 
> I would like to apply the following changes:
> 
> 1. NetBSD uses statfvs
> 2. passing possibly negative values to isdigit is undefined behavior:
>    http://www.opengroup.org/onlinepubs/009695399/functions/isdigit.html
> 3. passing possibly negative values to isspace is undefined behavior:
>    http://www.opengroup.org/onlinepubs/009695399/functions/isspace.html
> 4. last is possibly uninitialized.
> 5. recvfrom argument should be socklen_t not int:
>    http://www.opengroup.org/onlinepubs/007908775/xns/recvfrom.html
> 6. NetBSD uses <net/if_ether.h>
> 
> 1, 6 are NetBSD specific, the rest should be applied to everyone.
> 
> Ok to commit?
> 
> Thanks,
> 
> christos
> 
> diff -r fc30e7f4b9b3 src/solaris/native/java/io/UnixFileSystem_md.c
> --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Fri Jan 16 11:24:18 2009 -0500
> +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Mon Jan 22 16:25:36 2009 -0500
> @@ -47,6 +47,9 @@
>  #define readdir64 readdir
>  #define stat64 stat
>  #endif
> +#ifdef __NetBSD__
> +#define statfs statvfs
> +#endif
>  
>  /* -- Field IDs -- */
>  
> diff -r fc30e7f4b9b3 src/solaris/native/java/lang/UNIXProcess_md.c
> --- a/src/solaris/native/java/lang/UNIXProcess_md.c	Fri Jan 16 11:24:18 2009 -0500
> +++ b/src/solaris/native/java/lang/UNIXProcess_md.c	Mon Jan 22 16:25:36 2009 -0500
> @@ -377,7 +377,7 @@
>       */
>      while ((dirp = readdir(dp)) != NULL) {
>          int fd;
> -        if (isdigit(dirp->d_name[0]) &&
> +        if (isdigit((unsigned char)dirp->d_name[0]) &&
>              (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd + 2)
>              close(fd);
>      }
> diff -r fc30e7f4b9b3 src/solaris/native/java/net/Inet4AddressImpl.c
> --- a/src/solaris/native/java/net/Inet4AddressImpl.c	Fri Jan 16 11:24:18 2009 -0500
> +++ b/src/solaris/native/java/net/Inet4AddressImpl.c	Mon Jan 22 16:25:36 2009 -0500
> @@ -155,7 +155,7 @@
>       * Workaround for Solaris bug 4160367 - if a hostname contains a
>       * white space then 0.0.0.0 is returned
>       */
> -    if (isspace(hostname[0])) {
> +    if (isspace((unsigned char)hostname[0])) {
>  	JNU_ThrowByName(env, JNU_JAVANETPKG "UnknownHostException",
>  			(char *)hostname);
>  	JNU_ReleaseStringPlatformChars(env, host, hostname);
> @@ -172,7 +172,7 @@
>  	return NULL;
>      } else {
>  	int i = 0;
> -	struct addrinfo *itr, *last, *iterator = res;
> +	struct addrinfo *itr, *last = NULL, *iterator = res;
>  	while (iterator != NULL) {
>  	    int skip = 0;
>  	    itr = resNew;
> @@ -603,7 +603,8 @@
>  ping4(JNIEnv *env, jint fd, struct sockaddr_in* him, jint timeout,
>        struct sockaddr_in* netif, jint ttl) {
>      jint size;
> -    jint n, len, hlen1, icmplen;
> +    jint n, hlen1, icmplen;
> +    socklen_t len;
>      char sendbuf[1500];
>      char recvbuf[1500];
>      struct icmp *icmp;
> diff -r fc30e7f4b9b3 src/solaris/native/java/net/NetworkInterface.c
> --- a/src/solaris/native/java/net/NetworkInterface.c	Fri Jan 16 11:24:18 2009 -0500
> +++ b/src/solaris/native/java/net/NetworkInterface.c	Mon Jan 22 16:25:36 2009 -0500
> @@ -55,6 +55,8 @@
>  #include <net/if_var.h>
>  #elif defined(__OpenBSD__)
>  #include <netinet/if_ether.h>
> +#elif defined(__NetBSD__)
> +#include <net/if_ether.h>
>  #endif
>  #include <net/if_dl.h>
>  #include <netinet/in_var.h>
> 



From kurt at intricatesoftware.com  Fri Jan 23 13:06:28 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Fri, 23 Jan 2009 16:06:28 -0500
Subject: java.nio and SelectionKey.interestOps(int i)
In-Reply-To: <27acba740901210118x5f39ca1cj9b508dbc91eec9b3@mail.gmail.com>
References: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>	
	<49769BAD.2090009@intricatesoftware.com>
	<27acba740901210118x5f39ca1cj9b508dbc91eec9b3@mail.gmail.com>
Message-ID: <497A3154.8050007@intricatesoftware.com>

Hi Martin,

This looks like bug in your test program:
...
    if (selectionKey.isAcceptable()) {
	SocketChannel connection = serverSocketChannel.accept();
	connection.configureBlocking(false);
	connection.register(selector, SelectionKey.OP_READ);

The line above only registers the SocketChannel to only be
interested in read ops. SelectionKey.OP_READ | SelectionKey.OP_WRITE
works as expected.

Regards,
-Kurt

Martin Kihlgren wrote:
> Of course!
> 
> I will attach the code, and here is my results when I run it on two
> different machines:
> 
> On my linux box:
> ------------------------------8<---------------------------
> [0:zond at cthulhu ~/tmp]$uname -a
> Linux cthulhu 2.6.23 #3 SMP Mon Jan 21 10:44:04 CET 2008 i686 GNU/Linux
> [0:zond at cthulhu ~/tmp]$java -version
> java version "1.6.0_0"
> OpenJDK  Runtime Environment (build 1.6.0_0-b11)
> OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
> [0:zond at cthulhu ~/tmp]$md5sum SetInterestOpsTest.java
> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
> [0:zond at cthulhu ~/tmp]$javac SetInterestOpsTest.java
> [0:zond at cthulhu ~/tmp]$java SetInterestOpsTest
> Connecter connected
> Connecter sent test1
> Listener accepted connection
> Listener read test1
> Listener wrote test2
> Connecter received test2
> [0:zond at cthulhu ~/tmp]$
> ------------------------------8<---------------------------
> 
> On my OS X Tiger box:
> ------------------------------8<---------------------------
> [0:zond at sharkattack ~/tmp]$uname -a
> Darwin sharkattack.troja.ath.cx 8.11.1 Darwin Kernel Version 8.11.1:
> Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
> i386
> [0:zond at sharkattack ~/tmp]$java -version
> java version "1.6.0_03-p3"
> Java(TM) SE Runtime Environment (build
> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00)
> Java HotSpot(TM) Server VM (build
> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00, mixed mode)
> [0:zond at sharkattack ~/tmp]$md5sum SetInterestOpsTest.java
> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
> [0:zond at sharkattack ~/tmp]$javac SetInterestOpsTest.java
> [0:zond at sharkattack ~/tmp]$java SetInterestOpsTest
> Connecter connected
> Connecter sent test1
> Listener accepted connection
> Listener read test1
> ^C[130:zond at sharkattack ~/tmp]$
> ------------------------------8<---------------------------
> 
> regards,
> //Martin Kihlgren
> 
> On Wed, Jan 21, 2009 at 4:51 AM, Kurt Miller <kurt at intricatesoftware.com> wrote:
>> Hello Martin,
>>
>> Can you post a minimal test case that reproduces the issue?
>>
>> Thanks,
>> -Kurt
>>
>>
>> Martin Kihlgren wrote:
>>> Hello list!
>>>
>>> I have this problem that I thought maybe you could help explaining.
>>>
>>> I have this application, where a server thread loops around a
>>> select(), and then does stuff to the different SelectableChannels that
>>> pops out from the Selector.
>>>
>>> If something is read from a channel, for example, I send it to a
>>> handler. And if the handler wants to respond in some way, it adds it
>>> to a queue and then does interestOps(interestOps() &
>>> SelectionKey.OP_WRITE) on its SelectionKey. Then it does wakeup() on
>>> its Selector.
>>>
>>> In Sun's java 6 for linux, this works beautifully. The Selector wakes
>>> up, does another select, and finds that suddenly this
>>> SelectableChannel wants to be (and can be) written to.
>>>
>>> In SoyLatte, however, nothing happens! No matter if I wake the
>>> selector up one or many times, it doesn't recognize that the
>>> SelectableChannel and its SelectionKey is interested in OP_WRITE.
>>>
>>> Any ideas?
>>>
>>> regards,
>>> //Martin Kihlgren
>>>
>>



From zondolfin at gmail.com  Fri Jan 23 13:12:21 2009
From: zondolfin at gmail.com (Martin Kihlgren)
Date: Fri, 23 Jan 2009 22:12:21 +0100
Subject: java.nio and SelectionKey.interestOps(int i)
In-Reply-To: <497A3154.8050007@intricatesoftware.com>
References: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>
	<49769BAD.2090009@intricatesoftware.com>
	<27acba740901210118x5f39ca1cj9b508dbc91eec9b3@mail.gmail.com>
	<497A3154.8050007@intricatesoftware.com>
Message-ID: <27acba740901231312i7d3cbcabpbbce65c669c402e1@mail.gmail.com>

Oh, but my program waits for the connecting client to start sending -
I don't want to spend time selecting for OP_WRITE before I have
anything to write. So I reset the interestOps when the server has a
reply, and then expect the selector to return the SelectionKey when
the endpoint is ready for write.

Maybe one could consider this (changing the interestOps after having
registered the key) a weird thing to do, but I don't see anything that
indicates it should not work, and as you yourself has seen, it works
in most environments (except, afaik, that BSD and OS X).

regards,
//Martin

On Fri, Jan 23, 2009 at 10:06 PM, Kurt Miller
<kurt at intricatesoftware.com> wrote:
> Hi Martin,
>
> This looks like bug in your test program:
> ...
>    if (selectionKey.isAcceptable()) {
>        SocketChannel connection = serverSocketChannel.accept();
>        connection.configureBlocking(false);
>        connection.register(selector, SelectionKey.OP_READ);
>
> The line above only registers the SocketChannel to only be
> interested in read ops. SelectionKey.OP_READ | SelectionKey.OP_WRITE
> works as expected.
>
> Regards,
> -Kurt
>
> Martin Kihlgren wrote:
>> Of course!
>>
>> I will attach the code, and here is my results when I run it on two
>> different machines:
>>
>> On my linux box:
>> ------------------------------8<---------------------------
>> [0:zond at cthulhu ~/tmp]$uname -a
>> Linux cthulhu 2.6.23 #3 SMP Mon Jan 21 10:44:04 CET 2008 i686 GNU/Linux
>> [0:zond at cthulhu ~/tmp]$java -version
>> java version "1.6.0_0"
>> OpenJDK  Runtime Environment (build 1.6.0_0-b11)
>> OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
>> [0:zond at cthulhu ~/tmp]$md5sum SetInterestOpsTest.java
>> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
>> [0:zond at cthulhu ~/tmp]$javac SetInterestOpsTest.java
>> [0:zond at cthulhu ~/tmp]$java SetInterestOpsTest
>> Connecter connected
>> Connecter sent test1
>> Listener accepted connection
>> Listener read test1
>> Listener wrote test2
>> Connecter received test2
>> [0:zond at cthulhu ~/tmp]$
>> ------------------------------8<---------------------------
>>
>> On my OS X Tiger box:
>> ------------------------------8<---------------------------
>> [0:zond at sharkattack ~/tmp]$uname -a
>> Darwin sharkattack.troja.ath.cx 8.11.1 Darwin Kernel Version 8.11.1:
>> Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
>> i386
>> [0:zond at sharkattack ~/tmp]$java -version
>> java version "1.6.0_03-p3"
>> Java(TM) SE Runtime Environment (build
>> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00)
>> Java HotSpot(TM) Server VM (build
>> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00, mixed mode)
>> [0:zond at sharkattack ~/tmp]$md5sum SetInterestOpsTest.java
>> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
>> [0:zond at sharkattack ~/tmp]$javac SetInterestOpsTest.java
>> [0:zond at sharkattack ~/tmp]$java SetInterestOpsTest
>> Connecter connected
>> Connecter sent test1
>> Listener accepted connection
>> Listener read test1
>> ^C[130:zond at sharkattack ~/tmp]$
>> ------------------------------8<---------------------------
>>
>> regards,
>> //Martin Kihlgren
>>
>> On Wed, Jan 21, 2009 at 4:51 AM, Kurt Miller <kurt at intricatesoftware.com> wrote:
>>> Hello Martin,
>>>
>>> Can you post a minimal test case that reproduces the issue?
>>>
>>> Thanks,
>>> -Kurt
>>>
>>>
>>> Martin Kihlgren wrote:
>>>> Hello list!
>>>>
>>>> I have this problem that I thought maybe you could help explaining.
>>>>
>>>> I have this application, where a server thread loops around a
>>>> select(), and then does stuff to the different SelectableChannels that
>>>> pops out from the Selector.
>>>>
>>>> If something is read from a channel, for example, I send it to a
>>>> handler. And if the handler wants to respond in some way, it adds it
>>>> to a queue and then does interestOps(interestOps() &
>>>> SelectionKey.OP_WRITE) on its SelectionKey. Then it does wakeup() on
>>>> its Selector.
>>>>
>>>> In Sun's java 6 for linux, this works beautifully. The Selector wakes
>>>> up, does another select, and finds that suddenly this
>>>> SelectableChannel wants to be (and can be) written to.
>>>>
>>>> In SoyLatte, however, nothing happens! No matter if I wake the
>>>> selector up one or many times, it doesn't recognize that the
>>>> SelectableChannel and its SelectionKey is interested in OP_WRITE.
>>>>
>>>> Any ideas?
>>>>
>>>> regards,
>>>> //Martin Kihlgren
>>>>
>>>
>
>


From glewis at eyesbeyond.com  Fri Jan 23 14:05:54 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Fri, 23 Jan 2009 14:05:54 -0800
Subject: I would like to apply the following changes
In-Reply-To: <497A0E93.9080106@intricatesoftware.com>
References: <20090123162855.C07915654F@rebar.astron.com>
	<497A0E93.9080106@intricatesoftware.com>
Message-ID: <20090123220554.GA48711@misty.eyesbeyond.com>

On Fri, Jan 23, 2009 at 01:38:11PM -0500, Kurt Miller wrote:
> Sure these are fine.
> 
> Andrew has a good point. 2-5 should be submitted as bug reports
> to the main tree.

Agreed on both points :).

> Christos Zoulas wrote:
> > Hello,
> > 
> > I would like to apply the following changes:
> > 
> > 1. NetBSD uses statfvs
> > 2. passing possibly negative values to isdigit is undefined behavior:
> >    http://www.opengroup.org/onlinepubs/009695399/functions/isdigit.html
> > 3. passing possibly negative values to isspace is undefined behavior:
> >    http://www.opengroup.org/onlinepubs/009695399/functions/isspace.html
> > 4. last is possibly uninitialized.
> > 5. recvfrom argument should be socklen_t not int:
> >    http://www.opengroup.org/onlinepubs/007908775/xns/recvfrom.html
> > 6. NetBSD uses <net/if_ether.h>
> > 
> > 1, 6 are NetBSD specific, the rest should be applied to everyone.
> > 
> > Ok to commit?
> > 
> > Thanks,
> > 
> > christos
> > 
> > diff -r fc30e7f4b9b3 src/solaris/native/java/io/UnixFileSystem_md.c
> > --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Fri Jan 16 11:24:18 2009 -0500
> > +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Mon Jan 22 16:25:36 2009 -0500
> > @@ -47,6 +47,9 @@
> >  #define readdir64 readdir
> >  #define stat64 stat
> >  #endif
> > +#ifdef __NetBSD__
> > +#define statfs statvfs
> > +#endif
> >  
> >  /* -- Field IDs -- */
> >  
> > diff -r fc30e7f4b9b3 src/solaris/native/java/lang/UNIXProcess_md.c
> > --- a/src/solaris/native/java/lang/UNIXProcess_md.c	Fri Jan 16 11:24:18 2009 -0500
> > +++ b/src/solaris/native/java/lang/UNIXProcess_md.c	Mon Jan 22 16:25:36 2009 -0500
> > @@ -377,7 +377,7 @@
> >       */
> >      while ((dirp = readdir(dp)) != NULL) {
> >          int fd;
> > -        if (isdigit(dirp->d_name[0]) &&
> > +        if (isdigit((unsigned char)dirp->d_name[0]) &&
> >              (fd = strtol(dirp->d_name, NULL, 10)) >= from_fd + 2)
> >              close(fd);
> >      }
> > diff -r fc30e7f4b9b3 src/solaris/native/java/net/Inet4AddressImpl.c
> > --- a/src/solaris/native/java/net/Inet4AddressImpl.c	Fri Jan 16 11:24:18 2009 -0500
> > +++ b/src/solaris/native/java/net/Inet4AddressImpl.c	Mon Jan 22 16:25:36 2009 -0500
> > @@ -155,7 +155,7 @@
> >       * Workaround for Solaris bug 4160367 - if a hostname contains a
> >       * white space then 0.0.0.0 is returned
> >       */
> > -    if (isspace(hostname[0])) {
> > +    if (isspace((unsigned char)hostname[0])) {
> >  	JNU_ThrowByName(env, JNU_JAVANETPKG "UnknownHostException",
> >  			(char *)hostname);
> >  	JNU_ReleaseStringPlatformChars(env, host, hostname);
> > @@ -172,7 +172,7 @@
> >  	return NULL;
> >      } else {
> >  	int i = 0;
> > -	struct addrinfo *itr, *last, *iterator = res;
> > +	struct addrinfo *itr, *last = NULL, *iterator = res;
> >  	while (iterator != NULL) {
> >  	    int skip = 0;
> >  	    itr = resNew;
> > @@ -603,7 +603,8 @@
> >  ping4(JNIEnv *env, jint fd, struct sockaddr_in* him, jint timeout,
> >        struct sockaddr_in* netif, jint ttl) {
> >      jint size;
> > -    jint n, len, hlen1, icmplen;
> > +    jint n, hlen1, icmplen;
> > +    socklen_t len;
> >      char sendbuf[1500];
> >      char recvbuf[1500];
> >      struct icmp *icmp;
> > diff -r fc30e7f4b9b3 src/solaris/native/java/net/NetworkInterface.c
> > --- a/src/solaris/native/java/net/NetworkInterface.c	Fri Jan 16 11:24:18 2009 -0500
> > +++ b/src/solaris/native/java/net/NetworkInterface.c	Mon Jan 22 16:25:36 2009 -0500
> > @@ -55,6 +55,8 @@
> >  #include <net/if_var.h>
> >  #elif defined(__OpenBSD__)
> >  #include <netinet/if_ether.h>
> > +#elif defined(__NetBSD__)
> > +#include <net/if_ether.h>
> >  #endif
> >  #include <net/if_dl.h>
> >  #include <netinet/in_var.h>
> > 
> 

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From kurt at intricatesoftware.com  Fri Jan 23 16:12:38 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Fri, 23 Jan 2009 19:12:38 -0500
Subject: java.nio and SelectionKey.interestOps(int i)
In-Reply-To: <27acba740901231312i7d3cbcabpbbce65c669c402e1@mail.gmail.com>
References: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>	<49769BAD.2090009@intricatesoftware.com>	<27acba740901210118x5f39ca1cj9b508dbc91eec9b3@mail.gmail.com>	<497A3154.8050007@intricatesoftware.com>
	<27acba740901231312i7d3cbcabpbbce65c669c402e1@mail.gmail.com>
Message-ID: <497A5CF6.2010803@intricatesoftware.com>

Ahh ok, I see now. I see why it is happening on FreeBSD and I suppose
it may be the same reason OS X fails this. On FreeBSD (and OpenBSD too),
upon return from the poll() system call the complete pollfd array is
written to. So what's happening is that after the program prints
"Listener read " your program races around to the selector.select()
call before the fixer thread changes the interestOps to look for
writes. selector.select() is implemented by poll() and the poll
system call. The kernel copies the userland pollfd data to kernel
memory. fixer changes userland's copy of pollfd data to watch out
for writes too.  sel.wakeup() wakes up the poll system call which
overrights userland's pollfd data and erases the POLLOUT flag then
goes back and poll's again for just reads.

This works on Solaris and Linux I assume because the kernel
may write to just the revents field, not the whole struct.

http://www.opengroup.org/onlinepubs/009695399/functions/poll.html

Doesn't mention if events is reset or left untouched but it does
seem like a good idea to leave it alone upon return from the kernel.

Here's a simple test program to demonstrate the problem. You can
try it on OS X to see if it fails there too and file a bug report
against OS X.

#include <err.h>
#include <poll.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

struct pollfd fds[2];
int pipefds[2];

static void *
thread(void *arg) {
  sleep(1);
  fds[1].events = POLLIN | POLLOUT;
  write(pipefds[0], "", 1);
  return NULL;
}

int
main(int argc, char *argv[]) {
  pthread_t tid;

  if (pipe(pipefds) != 0)
    err(1, "pipe failed");

  fds[0].fd = pipefds[0];
  fds[0].events = POLLIN;

  fds[1].fd = pipefds[1];
  fds[1].events = POLLIN;

  if (pthread_create(&tid, NULL, thread, NULL) != 0)
    err(1, "pthread_create failed");

  poll(fds, 2, -1);

  if (fds[1].events != (POLLIN | POLLOUT)) {
    printf("events overwritten by kernel!\n");
    return 1;
  }

  return 0;
}

Martin Kihlgren wrote:
> Oh, but my program waits for the connecting client to start sending -
> I don't want to spend time selecting for OP_WRITE before I have
> anything to write. So I reset the interestOps when the server has a
> reply, and then expect the selector to return the SelectionKey when
> the endpoint is ready for write.
> 
> Maybe one could consider this (changing the interestOps after having
> registered the key) a weird thing to do, but I don't see anything that
> indicates it should not work, and as you yourself has seen, it works
> in most environments (except, afaik, that BSD and OS X).
> 
> regards,
> //Martin
> 
> On Fri, Jan 23, 2009 at 10:06 PM, Kurt Miller
> <kurt at intricatesoftware.com> wrote:
>> Hi Martin,
>>
>> This looks like bug in your test program:
>> ...
>>    if (selectionKey.isAcceptable()) {
>>        SocketChannel connection = serverSocketChannel.accept();
>>        connection.configureBlocking(false);
>>        connection.register(selector, SelectionKey.OP_READ);
>>
>> The line above only registers the SocketChannel to only be
>> interested in read ops. SelectionKey.OP_READ | SelectionKey.OP_WRITE
>> works as expected.
>>
>> Regards,
>> -Kurt
>>
>> Martin Kihlgren wrote:
>>> Of course!
>>>
>>> I will attach the code, and here is my results when I run it on two
>>> different machines:
>>>
>>> On my linux box:
>>> ------------------------------8<---------------------------
>>> [0:zond at cthulhu ~/tmp]$uname -a
>>> Linux cthulhu 2.6.23 #3 SMP Mon Jan 21 10:44:04 CET 2008 i686 GNU/Linux
>>> [0:zond at cthulhu ~/tmp]$java -version
>>> java version "1.6.0_0"
>>> OpenJDK  Runtime Environment (build 1.6.0_0-b11)
>>> OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
>>> [0:zond at cthulhu ~/tmp]$md5sum SetInterestOpsTest.java
>>> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
>>> [0:zond at cthulhu ~/tmp]$javac SetInterestOpsTest.java
>>> [0:zond at cthulhu ~/tmp]$java SetInterestOpsTest
>>> Connecter connected
>>> Connecter sent test1
>>> Listener accepted connection
>>> Listener read test1
>>> Listener wrote test2
>>> Connecter received test2
>>> [0:zond at cthulhu ~/tmp]$
>>> ------------------------------8<---------------------------
>>>
>>> On my OS X Tiger box:
>>> ------------------------------8<---------------------------
>>> [0:zond at sharkattack ~/tmp]$uname -a
>>> Darwin sharkattack.troja.ath.cx 8.11.1 Darwin Kernel Version 8.11.1:
>>> Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
>>> i386
>>> [0:zond at sharkattack ~/tmp]$java -version
>>> java version "1.6.0_03-p3"
>>> Java(TM) SE Runtime Environment (build
>>> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00)
>>> Java HotSpot(TM) Server VM (build
>>> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00, mixed mode)
>>> [0:zond at sharkattack ~/tmp]$md5sum SetInterestOpsTest.java
>>> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
>>> [0:zond at sharkattack ~/tmp]$javac SetInterestOpsTest.java
>>> [0:zond at sharkattack ~/tmp]$java SetInterestOpsTest
>>> Connecter connected
>>> Connecter sent test1
>>> Listener accepted connection
>>> Listener read test1
>>> ^C[130:zond at sharkattack ~/tmp]$
>>> ------------------------------8<---------------------------
>>>
>>> regards,
>>> //Martin Kihlgren
>>>
>>> On Wed, Jan 21, 2009 at 4:51 AM, Kurt Miller <kurt at intricatesoftware.com> wrote:
>>>> Hello Martin,
>>>>
>>>> Can you post a minimal test case that reproduces the issue?
>>>>
>>>> Thanks,
>>>> -Kurt
>>>>
>>>>
>>>> Martin Kihlgren wrote:
>>>>> Hello list!
>>>>>
>>>>> I have this problem that I thought maybe you could help explaining.
>>>>>
>>>>> I have this application, where a server thread loops around a
>>>>> select(), and then does stuff to the different SelectableChannels that
>>>>> pops out from the Selector.
>>>>>
>>>>> If something is read from a channel, for example, I send it to a
>>>>> handler. And if the handler wants to respond in some way, it adds it
>>>>> to a queue and then does interestOps(interestOps() &
>>>>> SelectionKey.OP_WRITE) on its SelectionKey. Then it does wakeup() on
>>>>> its Selector.
>>>>>
>>>>> In Sun's java 6 for linux, this works beautifully. The Selector wakes
>>>>> up, does another select, and finds that suddenly this
>>>>> SelectableChannel wants to be (and can be) written to.
>>>>>
>>>>> In SoyLatte, however, nothing happens! No matter if I wake the
>>>>> selector up one or many times, it doesn't recognize that the
>>>>> SelectableChannel and its SelectionKey is interested in OP_WRITE.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> regards,
>>>>> //Martin Kihlgren
>>>>>
>>
> 



From zondolfin at gmail.com  Fri Jan 23 17:15:15 2009
From: zondolfin at gmail.com (Martin Kihlgren)
Date: Sat, 24 Jan 2009 02:15:15 +0100
Subject: java.nio and SelectionKey.interestOps(int i)
In-Reply-To: <497A5CF6.2010803@intricatesoftware.com>
References: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>
	<49769BAD.2090009@intricatesoftware.com>
	<27acba740901210118x5f39ca1cj9b508dbc91eec9b3@mail.gmail.com>
	<497A3154.8050007@intricatesoftware.com>
	<27acba740901231312i7d3cbcabpbbce65c669c402e1@mail.gmail.com>
	<497A5CF6.2010803@intricatesoftware.com>
Message-ID: <27acba740901231715o317c6d79t2d4343bd3585333c@mail.gmail.com>

Well that certainly explains it!

I tried your test program, and it freezes before any output on both my
Linux 2.6.21 and my OS X Tiger.

On the other hand, now that I know what the problem is, I can simply
create a task for the thread doing the select, to change the
interestOps between selects instead. That way the overwrite won't
happen, and my program works again.

Thanks for the help and explanation - it really did help, and now my
project works fine on BSD systems as well :D

regards,
//Martin Kihlgren

On Sat, Jan 24, 2009 at 1:12 AM, Kurt Miller <kurt at intricatesoftware.com> wrote:
> Ahh ok, I see now. I see why it is happening on FreeBSD and I suppose
> it may be the same reason OS X fails this. On FreeBSD (and OpenBSD too),
> upon return from the poll() system call the complete pollfd array is
> written to. So what's happening is that after the program prints
> "Listener read " your program races around to the selector.select()
> call before the fixer thread changes the interestOps to look for
> writes. selector.select() is implemented by poll() and the poll
> system call. The kernel copies the userland pollfd data to kernel
> memory. fixer changes userland's copy of pollfd data to watch out
> for writes too.  sel.wakeup() wakes up the poll system call which
> overrights userland's pollfd data and erases the POLLOUT flag then
> goes back and poll's again for just reads.
>
> This works on Solaris and Linux I assume because the kernel
> may write to just the revents field, not the whole struct.
>
> http://www.opengroup.org/onlinepubs/009695399/functions/poll.html
>
> Doesn't mention if events is reset or left untouched but it does
> seem like a good idea to leave it alone upon return from the kernel.
>
> Here's a simple test program to demonstrate the problem. You can
> try it on OS X to see if it fails there too and file a bug report
> against OS X.
>
> #include <err.h>
> #include <poll.h>
> #include <pthread.h>
> #include <stdio.h>
> #include <unistd.h>
>
> struct pollfd fds[2];
> int pipefds[2];
>
> static void *
> thread(void *arg) {
>  sleep(1);
>  fds[1].events = POLLIN | POLLOUT;
>  write(pipefds[0], "", 1);
>  return NULL;
> }
>
> int
> main(int argc, char *argv[]) {
>  pthread_t tid;
>
>  if (pipe(pipefds) != 0)
>    err(1, "pipe failed");
>
>  fds[0].fd = pipefds[0];
>  fds[0].events = POLLIN;
>
>  fds[1].fd = pipefds[1];
>  fds[1].events = POLLIN;
>
>  if (pthread_create(&tid, NULL, thread, NULL) != 0)
>    err(1, "pthread_create failed");
>
>  poll(fds, 2, -1);
>
>  if (fds[1].events != (POLLIN | POLLOUT)) {
>    printf("events overwritten by kernel!\n");
>    return 1;
>  }
>
>  return 0;
> }
>
> Martin Kihlgren wrote:
>> Oh, but my program waits for the connecting client to start sending -
>> I don't want to spend time selecting for OP_WRITE before I have
>> anything to write. So I reset the interestOps when the server has a
>> reply, and then expect the selector to return the SelectionKey when
>> the endpoint is ready for write.
>>
>> Maybe one could consider this (changing the interestOps after having
>> registered the key) a weird thing to do, but I don't see anything that
>> indicates it should not work, and as you yourself has seen, it works
>> in most environments (except, afaik, that BSD and OS X).
>>
>> regards,
>> //Martin
>>
>> On Fri, Jan 23, 2009 at 10:06 PM, Kurt Miller
>> <kurt at intricatesoftware.com> wrote:
>>> Hi Martin,
>>>
>>> This looks like bug in your test program:
>>> ...
>>>    if (selectionKey.isAcceptable()) {
>>>        SocketChannel connection = serverSocketChannel.accept();
>>>        connection.configureBlocking(false);
>>>        connection.register(selector, SelectionKey.OP_READ);
>>>
>>> The line above only registers the SocketChannel to only be
>>> interested in read ops. SelectionKey.OP_READ | SelectionKey.OP_WRITE
>>> works as expected.
>>>
>>> Regards,
>>> -Kurt
>>>
>>> Martin Kihlgren wrote:
>>>> Of course!
>>>>
>>>> I will attach the code, and here is my results when I run it on two
>>>> different machines:
>>>>
>>>> On my linux box:
>>>> ------------------------------8<---------------------------
>>>> [0:zond at cthulhu ~/tmp]$uname -a
>>>> Linux cthulhu 2.6.23 #3 SMP Mon Jan 21 10:44:04 CET 2008 i686 GNU/Linux
>>>> [0:zond at cthulhu ~/tmp]$java -version
>>>> java version "1.6.0_0"
>>>> OpenJDK  Runtime Environment (build 1.6.0_0-b11)
>>>> OpenJDK Server VM (build 1.6.0_0-b11, mixed mode)
>>>> [0:zond at cthulhu ~/tmp]$md5sum SetInterestOpsTest.java
>>>> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
>>>> [0:zond at cthulhu ~/tmp]$javac SetInterestOpsTest.java
>>>> [0:zond at cthulhu ~/tmp]$java SetInterestOpsTest
>>>> Connecter connected
>>>> Connecter sent test1
>>>> Listener accepted connection
>>>> Listener read test1
>>>> Listener wrote test2
>>>> Connecter received test2
>>>> [0:zond at cthulhu ~/tmp]$
>>>> ------------------------------8<---------------------------
>>>>
>>>> On my OS X Tiger box:
>>>> ------------------------------8<---------------------------
>>>> [0:zond at sharkattack ~/tmp]$uname -a
>>>> Darwin sharkattack.troja.ath.cx 8.11.1 Darwin Kernel Version 8.11.1:
>>>> Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
>>>> i386
>>>> [0:zond at sharkattack ~/tmp]$java -version
>>>> java version "1.6.0_03-p3"
>>>> Java(TM) SE Runtime Environment (build
>>>> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00)
>>>> Java HotSpot(TM) Server VM (build
>>>> 1.6.0_03-p3-landonf_19_aug_2008_14_55-b00, mixed mode)
>>>> [0:zond at sharkattack ~/tmp]$md5sum SetInterestOpsTest.java
>>>> e538a1c50f35afef6ea1121a842ce8ce  SetInterestOpsTest.java
>>>> [0:zond at sharkattack ~/tmp]$javac SetInterestOpsTest.java
>>>> [0:zond at sharkattack ~/tmp]$java SetInterestOpsTest
>>>> Connecter connected
>>>> Connecter sent test1
>>>> Listener accepted connection
>>>> Listener read test1
>>>> ^C[130:zond at sharkattack ~/tmp]$
>>>> ------------------------------8<---------------------------
>>>>
>>>> regards,
>>>> //Martin Kihlgren
>>>>
>>>> On Wed, Jan 21, 2009 at 4:51 AM, Kurt Miller <kurt at intricatesoftware.com> wrote:
>>>>> Hello Martin,
>>>>>
>>>>> Can you post a minimal test case that reproduces the issue?
>>>>>
>>>>> Thanks,
>>>>> -Kurt
>>>>>
>>>>>
>>>>> Martin Kihlgren wrote:
>>>>>> Hello list!
>>>>>>
>>>>>> I have this problem that I thought maybe you could help explaining.
>>>>>>
>>>>>> I have this application, where a server thread loops around a
>>>>>> select(), and then does stuff to the different SelectableChannels that
>>>>>> pops out from the Selector.
>>>>>>
>>>>>> If something is read from a channel, for example, I send it to a
>>>>>> handler. And if the handler wants to respond in some way, it adds it
>>>>>> to a queue and then does interestOps(interestOps() &
>>>>>> SelectionKey.OP_WRITE) on its SelectionKey. Then it does wakeup() on
>>>>>> its Selector.
>>>>>>
>>>>>> In Sun's java 6 for linux, this works beautifully. The Selector wakes
>>>>>> up, does another select, and finds that suddenly this
>>>>>> SelectableChannel wants to be (and can be) written to.
>>>>>>
>>>>>> In SoyLatte, however, nothing happens! No matter if I wake the
>>>>>> selector up one or many times, it doesn't recognize that the
>>>>>> SelectableChannel and its SelectionKey is interested in OP_WRITE.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> regards,
>>>>>> //Martin Kihlgren
>>>>>>
>>>
>>
>
>


From kurt at intricatesoftware.com  Fri Jan 23 20:50:50 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Fri, 23 Jan 2009 23:50:50 -0500
Subject: java.nio and SelectionKey.interestOps(int i)
In-Reply-To: <27acba740901231715o317c6d79t2d4343bd3585333c@mail.gmail.com>
References: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>	<49769BAD.2090009@intricatesoftware.com>	<27acba740901210118x5f39ca1cj9b508dbc91eec9b3@mail.gmail.com>	<497A3154.8050007@intricatesoftware.com>	<27acba740901231312i7d3cbcabpbbce65c669c402e1@mail.gmail.com>	<497A5CF6.2010803@intricatesoftware.com>
	<27acba740901231715o317c6d79t2d4343bd3585333c@mail.gmail.com>
Message-ID: <497A9E2A.8050009@intricatesoftware.com>

Martin Kihlgren wrote:
> Well that certainly explains it!
>
> I tried your test program, and it freezes before any output on both my
> Linux 2.6.21 and my OS X Tiger.

Sorry I forgot the BSD's use bidirectional pipes and Linux, and OS X
have half duplex pipes. I wrote to the wrong fd for a half duplex pipe.
The test program should not freeze, it should complete without error
indicating the kernel doesn't write over the event field, or print an
error message. Below is a new version that should be portable and work
on OS X, Linux, etc.

> On the other hand, now that I know what the problem is, I can simply
> create a task for the thread doing the select, to change the
> interestOps between selects instead. That way the overwrite won't
> happen, and my program works again.
>
> Thanks for the help and explanation - it really did help, and now my
> project works fine on BSD systems as well :D

Your welcome. :-)

#include <err.h>
#include <poll.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

struct pollfd fds[2];
int pipefds[2];

static void *
thread(void *arg) {
 sleep(1);
 fds[0].events = POLLIN | POLLOUT;
 write(pipefds[1], "", 1);
 return NULL;
}

int
main(int argc, char *argv[]) {
 pthread_t tid;

 if (pipe(pipefds) != 0)
   err(1, "pipe failed");

 fds[0].fd = pipefds[0];
 fds[0].events = POLLIN;

 fds[1].fd = pipefds[1];
 fds[1].events = POLLIN;

 if (pthread_create(&tid, NULL, thread, NULL) != 0)
   err(1, "pthread_create failed");

 poll(fds, 2, -1);

 if (fds[0].events != (POLLIN | POLLOUT)) {
   printf("events overwritten by kernel!\n");
   return 1;
 }

 return 0;
}



From zondolfin at gmail.com  Sat Jan 24 03:03:53 2009
From: zondolfin at gmail.com (Martin Kihlgren)
Date: Sat, 24 Jan 2009 12:03:53 +0100
Subject: java.nio and SelectionKey.interestOps(int i)
In-Reply-To: <497A9E2A.8050009@intricatesoftware.com>
References: <27acba740901181545l497e5ff4wf3cf4366f6fe1040@mail.gmail.com>
	<49769BAD.2090009@intricatesoftware.com>
	<27acba740901210118x5f39ca1cj9b508dbc91eec9b3@mail.gmail.com>
	<497A3154.8050007@intricatesoftware.com>
	<27acba740901231312i7d3cbcabpbbce65c669c402e1@mail.gmail.com>
	<497A5CF6.2010803@intricatesoftware.com>
	<27acba740901231715o317c6d79t2d4343bd3585333c@mail.gmail.com>
	<497A9E2A.8050009@intricatesoftware.com>
Message-ID: <27acba740901240303s240aea15w52fb6dd91b32048e@mail.gmail.com>

Yup, that one worked - on OS X it talked about overwritten events, on
Linux it exited silently.

But, to be honest, I can't be arsed to make a serious complaint about
this. Anyone that feel they have the energy is welcome to, of course
:)

regards,
//Martin

On Sat, Jan 24, 2009 at 5:50 AM, Kurt Miller <kurt at intricatesoftware.com> wrote:
> Martin Kihlgren wrote:
>> Well that certainly explains it!
>>
>> I tried your test program, and it freezes before any output on both my
>> Linux 2.6.21 and my OS X Tiger.
>
> Sorry I forgot the BSD's use bidirectional pipes and Linux, and OS X
> have half duplex pipes. I wrote to the wrong fd for a half duplex pipe.
> The test program should not freeze, it should complete without error
> indicating the kernel doesn't write over the event field, or print an
> error message. Below is a new version that should be portable and work
> on OS X, Linux, etc.
>
>> On the other hand, now that I know what the problem is, I can simply
>> create a task for the thread doing the select, to change the
>> interestOps between selects instead. That way the overwrite won't
>> happen, and my program works again.
>>
>> Thanks for the help and explanation - it really did help, and now my
>> project works fine on BSD systems as well :D
>
> Your welcome. :-)
>
> #include <err.h>
> #include <poll.h>
> #include <pthread.h>
> #include <stdio.h>
> #include <unistd.h>
>
> struct pollfd fds[2];
> int pipefds[2];
>
> static void *
> thread(void *arg) {
>  sleep(1);
>  fds[0].events = POLLIN | POLLOUT;
>  write(pipefds[1], "", 1);
>  return NULL;
> }
>
> int
> main(int argc, char *argv[]) {
>  pthread_t tid;
>
>  if (pipe(pipefds) != 0)
>   err(1, "pipe failed");
>
>  fds[0].fd = pipefds[0];
>  fds[0].events = POLLIN;
>
>  fds[1].fd = pipefds[1];
>  fds[1].events = POLLIN;
>
>  if (pthread_create(&tid, NULL, thread, NULL) != 0)
>   err(1, "pthread_create failed");
>
>  poll(fds, 2, -1);
>
>  if (fds[0].events != (POLLIN | POLLOUT)) {
>   printf("events overwritten by kernel!\n");
>   return 1;
>  }
>
>  return 0;
> }
>
>


From kurt at intricatesoftware.com  Sun Jan 25 05:40:29 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Sun, 25 Jan 2009 13:40:29 +0000
Subject: hg: bsd-port/bsd-port/jdk: 2 new changesets
Message-ID: <20090125134052.C2F10E08B@hg.openjdk.java.net>

Changeset: 2e8cd6d78858
Author:    kurt
Date:      2009-01-25 08:32 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/2e8cd6d78858

iconv comes with OS X so adjust ICONV_PATH so that it is
always used. Revewied/tested by Landon Fuller.

! make/java/instrument/Makefile
! make/java/npt/Makefile
! make/sun/splashscreen/Makefile

Changeset: 3497f1f1afa4
Author:    kurt
Date:      2009-01-25 08:36 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3497f1f1afa4

Set the default PACKAGE_PATH on OS X to point to /opt/local.
On OS X PACKAGE_PATH is only used for specifying user installed
fonts and MacPorts uses /opt/local by default. Reveiwed/tested
by Landon Fuller

! make/common/Defs.gmk



From kurt at intricatesoftware.com  Sun Jan 25 05:42:19 2009
From: kurt at intricatesoftware.com (kurt at intricatesoftware.com)
Date: Sun, 25 Jan 2009 13:42:19 +0000
Subject: hg: bsd-port/bsd-port/corba: Set the default PACKAGE_PATH on OS X to
	point to /opt/local.
Message-ID: <20090125134220.54A59E090@hg.openjdk.java.net>

Changeset: 00bde93e84a1
Author:    kurt
Date:      2009-01-25 08:37 -0500
URL:       http://hg.openjdk.java.net/bsd-port/bsd-port/corba/rev/00bde93e84a1

Set the default PACKAGE_PATH on OS X to point to /opt/local.
On OS X PACKAGE_PATH is only used for specifying user installed
fonts and MacPorts uses /opt/local by default. Reveiwed/tested
by Landon Fuller

! make/common/Defs.gmk



From christos at zoulas.com  Tue Jan 27 09:53:10 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Tue, 27 Jan 2009 12:53:10 -0500
Subject: I would like to apply the following changes
In-Reply-To: <17c6771e0901230924p79d2d540xd0ff66516754e095@mail.gmail.com>
	from Andrew John Hughes (Jan 23,  5:24pm)
Message-ID: <20090127175310.C0BED5654E@rebar.astron.com>

On Jan 23,  5:24pm, gnu_andrew at member.fsf.org (Andrew John Hughes) wrote:
-- Subject: Re: I would like to apply the following changes

| 2009/1/23 Christos Zoulas <christos at zoulas.com>:
| > Hello,
| >
| > I would like to apply the following changes:
| >
| > 1. NetBSD uses statfvs
| > 2. passing possibly negative values to isdigit is undefined behavior:
| >   http://www.opengroup.org/onlinepubs/009695399/functions/isdigit.html
| > 3. passing possibly negative values to isspace is undefined behavior:
| >   http://www.opengroup.org/onlinepubs/009695399/functions/isspace.html
| > 4. last is possibly uninitialized.
| > 5. recvfrom argument should be socklen_t not int:
| >   http://www.opengroup.org/onlinepubs/007908775/xns/recvfrom.html
| > 6. NetBSD uses <net/if_ether.h>
| >
| > 1, 6 are NetBSD specific, the rest should be applied to everyone.
| 
| Are 2-5 general enough they should actually be sent to the main OpenJDK7 tree?

What's the procedure for doing that?

christos


From gnu_andrew at member.fsf.org  Tue Jan 27 11:38:05 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 27 Jan 2009 19:38:05 +0000
Subject: I would like to apply the following changes
In-Reply-To: <20090127175310.C0BED5654E@rebar.astron.com>
References: <17c6771e0901230924p79d2d540xd0ff66516754e095@mail.gmail.com>
	<20090127175310.C0BED5654E@rebar.astron.com>
Message-ID: <17c6771e0901271138j158da03cx98a5202b945932d9@mail.gmail.com>

2009/1/27 Christos Zoulas <christos at zoulas.com>:
> On Jan 23,  5:24pm, gnu_andrew at member.fsf.org (Andrew John Hughes) wrote:
> -- Subject: Re: I would like to apply the following changes
>
> | 2009/1/23 Christos Zoulas <christos at zoulas.com>:
> | > Hello,
> | >
> | > I would like to apply the following changes:
> | >
> | > 1. NetBSD uses statfvs
> | > 2. passing possibly negative values to isdigit is undefined behavior:
> | >   http://www.opengroup.org/onlinepubs/009695399/functions/isdigit.html
> | > 3. passing possibly negative values to isspace is undefined behavior:
> | >   http://www.opengroup.org/onlinepubs/009695399/functions/isspace.html
> | > 4. last is possibly uninitialized.
> | > 5. recvfrom argument should be socklen_t not int:
> | >   http://www.opengroup.org/onlinepubs/007908775/xns/recvfrom.html
> | > 6. NetBSD uses <net/if_ether.h>
> | >
> | > 1, 6 are NetBSD specific, the rest should be applied to everyone.
> |
> | Are 2-5 general enough they should actually be sent to the main OpenJDK7 tree?
>
> What's the procedure for doing that?
>
> christos
>

http://openjdk.java.net/contribute/

The mailing list for these is probably core-libs-dev.
-- 
Andrew :-)

IcedTea/OpenJDK Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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

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


From christos at zoulas.com  Tue Jan 27 17:16:33 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Tue, 27 Jan 2009 20:16:33 -0500
Subject: Missing binary files in build?
Message-ID: <20090128011633.D41F156550@rebar.astron.com>


My build from 1.6 fails without the following patch. Why doesn't anyone
else need it?

christos

diff -r 3497f1f1afa4 make/common/internal/BinaryPlugs.gmk
--- a/make/common/internal/BinaryPlugs.gmk      Sun Jan 25 08:36:08 2009 -0500
+++ b/make/common/internal/BinaryPlugs.gmk      Sat Jan 27 20:13:52 2009 -0500
@@ -62,7 +62,13 @@
 com/sun/jmx/snmp/SnmpVarBindList.class \
 com/sun/jmx/snmp/daemon/SendQ.class \
 com/sun/jmx/snmp/daemon/SnmpInformRequest.class \
-com/sun/jmx/snmp/daemon/SnmpSession.class
+com/sun/jmx/snmp/daemon/SnmpSession.class \
+com/sun/jmx/snmp/daemon/SnmpQManager.class \
+com/sun/jmx/snmp/daemon/SnmpRequestCounter.class \ 
+com/sun/jmx/snmp/daemon/SnmpSocket.class \
+com/sun/jmx/snmp/daemon/SnmpResponseHandler.class \
+com/sun/jmx/snmp/daemon/WaitQ.class \
+com/sun/jmx/snmp/Timestamp.class

 PLUG_SOUND_CLASS_NAMES = \
 com/sun/media/sound/AbstractPlayer.class \



From mvfranz at gmail.com  Tue Jan 27 18:27:46 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Tue, 27 Jan 2009 21:27:46 -0500
Subject: Missing binary files in build?
In-Reply-To: <20090128011633.D41F156550@rebar.astron.com>
References: <20090128011633.D41F156550@rebar.astron.com>
Message-ID: <fee4d890901271827x6128b287kff3f137409aa2495@mail.gmail.com>

Christos,

I just cloned the port-bsd repo and the build finished without a problem.
Do you have the latest code?

Michael
On Tue, Jan 27, 2009 at 8:16 PM, Christos Zoulas <christos at zoulas.com>wrote:

>
> My build from 1.6 fails without the following patch. Why doesn't anyone
> else need it?
>
> christos
>
> diff -r 3497f1f1afa4 make/common/internal/BinaryPlugs.gmk
> --- a/make/common/internal/BinaryPlugs.gmk      Sun Jan 25 08:36:08 2009
> -0500
> +++ b/make/common/internal/BinaryPlugs.gmk      Sat Jan 27 20:13:52 2009
> -0500
> @@ -62,7 +62,13 @@
>  com/sun/jmx/snmp/SnmpVarBindList.class \
>  com/sun/jmx/snmp/daemon/SendQ.class \
>  com/sun/jmx/snmp/daemon/SnmpInformRequest.class \
> -com/sun/jmx/snmp/daemon/SnmpSession.class
> +com/sun/jmx/snmp/daemon/SnmpSession.class \
> +com/sun/jmx/snmp/daemon/SnmpQManager.class \
> +com/sun/jmx/snmp/daemon/SnmpRequestCounter.class \
> +com/sun/jmx/snmp/daemon/SnmpSocket.class \
> +com/sun/jmx/snmp/daemon/SnmpResponseHandler.class \
> +com/sun/jmx/snmp/daemon/WaitQ.class \
> +com/sun/jmx/snmp/Timestamp.class
>
>  PLUG_SOUND_CLASS_NAMES = \
>  com/sun/media/sound/AbstractPlayer.class \
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090127/943c5138/attachment.html 

From christos at zoulas.com  Tue Jan 27 18:36:44 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Tue, 27 Jan 2009 21:36:44 -0500
Subject: Missing binary files in build?
In-Reply-To: <fee4d890901271827x6128b287kff3f137409aa2495@mail.gmail.com>
	from Michael Franz (Jan 27,  9:27pm)
Message-ID: <20090128023644.4A3EB5654E@rebar.astron.com>

On Jan 27,  9:27pm, mvfranz at gmail.com (Michael Franz) wrote:
-- Subject: Re: Missing binary files in build?

| Christos,
| 
| I just cloned the port-bsd repo and the build finished without a problem.
| Do you have the latest code?
| 
| Michael

Yes, are you using as your starting jdk 1.6? Also I think that there is
a bug in mercurial. NetBSD has moved to 64 bit time_t and now I get:

hg push
pushing to ssh://christos at hg.openjdk.java.net/bsd-port/bsd-port/hotspot
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 3 files
remote: snapshot taken
remote: error: changegroup.9.jnotify hook raised an exception: timestamp out of range for platform time_t

christos


From mvfranz at gmail.com  Tue Jan 27 18:41:31 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Tue, 27 Jan 2009 21:41:31 -0500
Subject: Missing binary files in build?
In-Reply-To: <20090128023644.4A3EB5654E@rebar.astron.com>
References: <fee4d890901271827x6128b287kff3f137409aa2495@mail.gmail.com>
	<20090128023644.4A3EB5654E@rebar.astron.com>
Message-ID: <fee4d890901271841u581ee549p3a5f308ff352c0b4@mail.gmail.com>

> Yes, are you using as your starting jdk 1.6?

Ah,  I am building with 1.7, since Apple's JDK's (5/6) don't work for
building OpenJDK 7.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090127/d8e822ad/attachment.html 

From glewis at eyesbeyond.com  Tue Jan 27 23:11:53 2009
From: glewis at eyesbeyond.com (Greg Lewis)
Date: Tue, 27 Jan 2009 23:11:53 -0800
Subject: Missing binary files in build?
In-Reply-To: <20090128011633.D41F156550@rebar.astron.com>
References: <20090128011633.D41F156550@rebar.astron.com>
Message-ID: <20090128071153.GA61932@misty.eyesbeyond.com>

G'day Christos,

On Tue, Jan 27, 2009 at 08:16:33PM -0500, Christos Zoulas wrote:
> My build from 1.6 fails without the following patch. Why doesn't anyone
> else need it?

Where did you get your binary plugins from?  I'm using a set I picked up
from Kurt (I think!) at one point based on IcedTea.  Did you maybe just
pull the current Linux or Solaris ones off of the OpenJDK site?

If you have a different set then that likely explains the difference.

> christos
> 
> diff -r 3497f1f1afa4 make/common/internal/BinaryPlugs.gmk
> --- a/make/common/internal/BinaryPlugs.gmk      Sun Jan 25 08:36:08 2009 -0500
> +++ b/make/common/internal/BinaryPlugs.gmk      Sat Jan 27 20:13:52 2009 -0500
> @@ -62,7 +62,13 @@
>  com/sun/jmx/snmp/SnmpVarBindList.class \
>  com/sun/jmx/snmp/daemon/SendQ.class \
>  com/sun/jmx/snmp/daemon/SnmpInformRequest.class \
> -com/sun/jmx/snmp/daemon/SnmpSession.class
> +com/sun/jmx/snmp/daemon/SnmpSession.class \
> +com/sun/jmx/snmp/daemon/SnmpQManager.class \
> +com/sun/jmx/snmp/daemon/SnmpRequestCounter.class \ 
> +com/sun/jmx/snmp/daemon/SnmpSocket.class \
> +com/sun/jmx/snmp/daemon/SnmpResponseHandler.class \
> +com/sun/jmx/snmp/daemon/WaitQ.class \
> +com/sun/jmx/snmp/Timestamp.class
> 
>  PLUG_SOUND_CLASS_NAMES = \
>  com/sun/media/sound/AbstractPlayer.class \
> 

-- 
Greg Lewis                          Email   : glewis at eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis at FreeBSD.org


From christos at zoulas.com  Wed Jan 28 06:02:15 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 28 Jan 2009 09:02:15 -0500
Subject: Missing binary files in build?
In-Reply-To: <20090128071153.GA61932@misty.eyesbeyond.com>
	from Greg Lewis (Jan 27, 11:11pm)
Message-ID: <20090128140215.1F2345654E@rebar.astron.com>

On Jan 27, 11:11pm, glewis at eyesbeyond.com (Greg Lewis) wrote:
-- Subject: Re: Missing binary files in build?

| G'day Christos,
| 
| On Tue, Jan 27, 2009 at 08:16:33PM -0500, Christos Zoulas wrote:
| > My build from 1.6 fails without the following patch. Why doesn't anyone
| > else need it?
| 
| Where did you get your binary plugins from?  I'm using a set I picked up
| from Kurt (I think!) at one point based on IcedTea.  Did you maybe just
| pull the current Linux or Solaris ones off of the OpenJDK site?
| 
| If you have a different set then that likely explains the difference.

I pulled them out of the 1.6 jdk. I think it makes sense to be able to
build from a standard, released jdk.

christos


From kurt at intricatesoftware.com  Wed Jan 28 08:06:08 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Wed, 28 Jan 2009 11:06:08 -0500
Subject: Missing binary files in build?
In-Reply-To: <20090128140215.1F2345654E@rebar.astron.com>
References: <20090128140215.1F2345654E@rebar.astron.com>
Message-ID: <49808270.7060100@intricatesoftware.com>

Christos Zoulas wrote:
> On Jan 27, 11:11pm, glewis at eyesbeyond.com (Greg Lewis) wrote:
> -- Subject: Re: Missing binary files in build?
> 
> | G'day Christos,
> | 
> | On Tue, Jan 27, 2009 at 08:16:33PM -0500, Christos Zoulas wrote:
> | > My build from 1.6 fails without the following patch. Why doesn't anyone
> | > else need it?
> | 
> | Where did you get your binary plugins from?  I'm using a set I picked up
> | from Kurt (I think!) at one point based on IcedTea.  Did you maybe just
> | pull the current Linux or Solaris ones off of the OpenJDK site?
> | 
> | If you have a different set then that likely explains the difference.
> 
> I pulled them out of the 1.6 jdk. I think it makes sense to be able to
> build from a standard, released jdk.

Hi Christos,

If your goal is to make packages available, I'd recommend using the
IcedTea plugs under the GLP. Sun's binary plugs come with an defend
and indemnify clause (even lawsuits without basis cost quite a lot
to defend against). INAL but I doubt using 1.6 binary's in OpenJDK is
something that is allowed by the license they are released under. For
reference see this link:

http://java.sun.com/javase/6/jre-6u11-license.txt

Only snmp & sound are left using the binary plugs. Hopefully Sun will
finish replacing them with OpenJDK/GPL code this year. In the mean time
use this for the bsd-port:

http://www.intricatesoftware.com/distfiles/jdk-7-icedtea-plugs-1.6a.tar.gz

Regards,
-Kurt


From christos at zoulas.com  Wed Jan 28 08:16:31 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Wed, 28 Jan 2009 11:16:31 -0500
Subject: Missing binary files in build?
In-Reply-To: <49808270.7060100@intricatesoftware.com>
	from Kurt Miller (Jan 28, 11:06am)
Message-ID: <20090128161631.9E62C5654E@rebar.astron.com>

On Jan 28, 11:06am, kurt at intricatesoftware.com (Kurt Miller) wrote:
-- Subject: Re: Missing binary files in build?

| Hi Christos,
| 
| If your goal is to make packages available, I'd recommend using the
| IcedTea plugs under the GLP. Sun's binary plugs come with an defend
| and indemnify clause (even lawsuits without basis cost quite a lot
| to defend against). INAL but I doubt using 1.6 binary's in OpenJDK is
| something that is allowed by the license they are released under. For
| reference see this link:
| 
| http://java.sun.com/javase/6/jre-6u11-license.txt
| 
| Only snmp & sound are left using the binary plugs. Hopefully Sun will
| finish replacing them with OpenJDK/GPL code this year. In the mean time
| use this for the bsd-port:
| 
| http://www.intricatesoftware.com/distfiles/jdk-7-icedtea-plugs-1.6a.tar.gz

Great, I will try that then. I did not know that I could release binary
packages. What's the process for that? I just compile, build a tar file
and put them somewhere for anonymous ftp? Or there is something more
complicated?

Thanks again for all the useful information!

christos


From kurt at intricatesoftware.com  Wed Jan 28 08:39:53 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Wed, 28 Jan 2009 11:39:53 -0500
Subject: Missing binary files in build?
In-Reply-To: <20090128161631.9E62C5654E@rebar.astron.com>
References: <20090128161631.9E62C5654E@rebar.astron.com>
Message-ID: <49808A59.5080502@intricatesoftware.com>

Christos Zoulas wrote:
> On Jan 28, 11:06am, kurt at intricatesoftware.com (Kurt Miller) wrote:
> -- Subject: Re: Missing binary files in build?
> 
> | Hi Christos,
> | 
> | If your goal is to make packages available, I'd recommend using the
> | IcedTea plugs under the GLP. Sun's binary plugs come with an defend
> | and indemnify clause (even lawsuits without basis cost quite a lot
> | to defend against). INAL but I doubt using 1.6 binary's in OpenJDK is
> | something that is allowed by the license they are released under. For
> | reference see this link:
> | 
> | http://java.sun.com/javase/6/jre-6u11-license.txt
> | 
> | Only snmp & sound are left using the binary plugs. Hopefully Sun will
> | finish replacing them with OpenJDK/GPL code this year. In the mean time
> | use this for the bsd-port:
> | 
> | http://www.intricatesoftware.com/distfiles/jdk-7-icedtea-plugs-1.6a.tar.gz
> 
> Great, I will try that then. I did not know that I could release binary
> packages. What's the process for that? I just compile, build a tar file
> and put them somewhere for anonymous ftp? Or there is something more
> complicated?

Yup that's it. OpenJDK & bsd-port are GPL, the plugs above are GPL so
the result is a GPL licensed package.

> Thanks again for all the useful information!

Your welcome.

Regards,
-Kurt


From garcia at osl.iu.edu  Thu Jan 29 11:27:58 2009
From: garcia at osl.iu.edu (Ronald Garcia)
Date: Thu, 29 Jan 2009 13:27:58 -0600
Subject: Building on Mac OS X 10.5.6
Message-ID: <F1710E97-C3D7-41AE-BDEF-DF9BC3520E0D@osl.iu.edu>

Hi all,

I just recently installed Mercurial, fcloned the BSD port of OpenJDK,  
and built it, but I ended up doing a few unexpected things to get  
compilation to complete.  I suspect I may be messing up some aspect of  
the build process given prior reports of successful builds on the  
mailing list.

Some info on my setup:
- a recent (circa october 2008) Mac Powerbook running OS X 10.5.6,  
with Xcode Developer Tools 3.1.2


First, I modified my make command from that given at the URL:
http://landonf.bikemonkey.org/2008/08/20

My build line is as follows:

make \
ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 \
ALT_BINARY_PLUGS_PATH=/usr/local/lib/jdk-7-icedtea-plugs \
ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \
ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \
ALT_CUPS_HEADERS_PATH=/usr/include \
ANT_HOME=/usr/share/ant \
NO_DOCS=true \
HOTSPOT_BUILD_JOBS=1 \
DEVTOOLS_PATH=/usr/bin \
LANG=C

The particular changes I made:
  - added "LANG=C" so as not to clash with Mercurial's documentation  
suggesting to set LANG=utf8...
  - added "DEVTOOLS_PATH=/usr/bin" because it wasn't set right by  
default
  - changed ALT_BINARY_PLUGS_PATH to reflect where I installed it
  - changed ALT_BOOTDIR to point to the correct filename for soylatte

As you can see, I used soylatte to bootstrap the build.  I was  
surprised that building died until I explicitly set
DEVTOOLS.

Once I did the above, I found that libsplashscreen would not build.   
To get libsplashscreen.dylib to build, I ended up modifying the file:
bsd-port/jdk/make/sun/splashscreen/Makefile

The command for building it was not including -liconv or the  
directory.  My changes to the Makefile were essentially as follows.

===================================<Snip! 
 >===================================
ifneq ($(PLATFORM), windows)
   CFLAGS += -DWITH_X11
   ifeq ($(PLATFORM), bsd)
     CFLAGS += -DPNG_NO_MMX_CODE
     ifeq ($(OS_VENDOR), Apple)
# Begin addition!
       ICONV_PATH = /usr
       CPPFLAGS += -I$(ICONV_PATH)/include
       OTHER_LDLIBS += -L$(ICONV_PATH)/lib -liconv
# End addition!
===================================<snip! 
 >===================================


My question is this:  Am I missing something in the build process such  
that DEVTOOLS_PATH isn't getting set on its own and that is causing  
ICONV to not get included on the build path?

I apologize if this has been addressed before, but I haven't seen any  
relevant information while scouring the archives.

Thanks,
ron



From kurt at intricatesoftware.com  Thu Jan 29 13:07:15 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Thu, 29 Jan 2009 16:07:15 -0500
Subject: Building on Mac OS X 10.5.6
In-Reply-To: <F1710E97-C3D7-41AE-BDEF-DF9BC3520E0D@osl.iu.edu>
References: <F1710E97-C3D7-41AE-BDEF-DF9BC3520E0D@osl.iu.edu>
Message-ID: <49821A83.7060106@intricatesoftware.com>

Hi Ron,

Ronald Garcia wrote:
> Hi all,
> 
> I just recently installed Mercurial, fcloned the BSD port of OpenJDK,  
> and built it, but I ended up doing a few unexpected things to get  
> compilation to complete.  I suspect I may be messing up some aspect of  
> the build process given prior reports of successful builds on the  
> mailing list.
> 
> Some info on my setup:
> - a recent (circa october 2008) Mac Powerbook running OS X 10.5.6,  
> with Xcode Developer Tools 3.1.2
> 
> 
> First, I modified my make command from that given at the URL:
> http://landonf.bikemonkey.org/2008/08/20
> 
> My build line is as follows:
> 
> make \
> ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 \
> ALT_BINARY_PLUGS_PATH=/usr/local/lib/jdk-7-icedtea-plugs \
> ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \
> ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \
> ALT_CUPS_HEADERS_PATH=/usr/include \
> ANT_HOME=/usr/share/ant \
> NO_DOCS=true \
> HOTSPOT_BUILD_JOBS=1 \
> DEVTOOLS_PATH=/usr/bin \
> LANG=C
> 
> The particular changes I made:
>   - added "LANG=C" so as not to clash with Mercurial's documentation  
> suggesting to set LANG=utf8...
>   - added "DEVTOOLS_PATH=/usr/bin" because it wasn't set right by  
> default
>   - changed ALT_BINARY_PLUGS_PATH to reflect where I installed it
>   - changed ALT_BOOTDIR to point to the correct filename for soylatte
> 
> As you can see, I used soylatte to bootstrap the build.  I was  
> surprised that building died until I explicitly set
> DEVTOOLS.
> 
> Once I did the above, I found that libsplashscreen would not build.   
> To get libsplashscreen.dylib to build, I ended up modifying the file:
> bsd-port/jdk/make/sun/splashscreen/Makefile
> 
> The command for building it was not including -liconv or the  
> directory.  My changes to the Makefile were essentially as follows.
> 
> ===================================<Snip! 
>  >===================================
> ifneq ($(PLATFORM), windows)
>    CFLAGS += -DWITH_X11
>    ifeq ($(PLATFORM), bsd)
>      CFLAGS += -DPNG_NO_MMX_CODE
>      ifeq ($(OS_VENDOR), Apple)
> # Begin addition!
>        ICONV_PATH = /usr
>        CPPFLAGS += -I$(ICONV_PATH)/include
>        OTHER_LDLIBS += -L$(ICONV_PATH)/lib -liconv
> # End addition!
> ===================================<snip! 
>  >===================================
> 
> 
> My question is this:  Am I missing something in the build process such  
> that DEVTOOLS_PATH isn't getting set on its own and that is causing  
> ICONV to not get included on the build path?

I recently corrected several path defaults, including the ones you
are hitting now. Please retry after updating your tree (hg fpull,
hg fupdate). You should no longer need to set ALT_CUPS_HEADERS_PATH
and DEVTOOLS_PATH on OS X.

> I apologize if this has been addressed before, but I haven't seen any  
> relevant information while scouring the archives.

Regards,
-Kurt


From garcia at osl.iu.edu  Thu Jan 29 17:22:56 2009
From: garcia at osl.iu.edu (Ronald Garcia)
Date: Thu, 29 Jan 2009 19:22:56 -0600
Subject: Building on Mac OS X 10.5.6
In-Reply-To: <49821A83.7060106@intricatesoftware.com>
References: <F1710E97-C3D7-41AE-BDEF-DF9BC3520E0D@osl.iu.edu>
	<49821A83.7060106@intricatesoftware.com>
Message-ID: <24622727-E319-4BB0-81A5-90512ADAB633@osl.iu.edu>

Hi Kurt,

Thanks for the fast reply.  I just ran hg fpull and hg fupdate.  make  
still seems to need DEVTOOLS_PATH (things are still building, so I  
don't know yet if I also need ALT_CUPS_HEADERS_PATH).  I also had to  
add LC_ALL=C (I must not have had it set last time).
Also, as it turns out, I still needed my changes to the splashscreen  
Makefile for building to succeed.


So my current build process is using the following command line:

make \
ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 \
ALT_BINARY_PLUGS_PATH=/usr/local/lib/jdk-7-icedtea-plugs \
ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \
ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \
ANT_HOME=/usr/share/ant \
NO_DOCS=true \
HOTSPOT_BUILD_JOBS=1 \
DEVTOOLS_PATH=/usr/bin \
LC_ALL=C \
LANG=C

and a modified makefile for splashscreen

Cheers,
ron



On Jan 29, 2009, at 3:07 PM, Kurt Miller wrote:

>> My question is this:  Am I missing something in the build process  
>> such
>> that DEVTOOLS_PATH isn't getting set on its own and that is causing
>> ICONV to not get included on the build path?
>
> I recently corrected several path defaults, including the ones you
> are hitting now. Please retry after updating your tree (hg fpull,
> hg fupdate). You should no longer need to set ALT_CUPS_HEADERS_PATH
> and DEVTOOLS_PATH on OS X.



From kurt at intricatesoftware.com  Thu Jan 29 18:57:12 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Thu, 29 Jan 2009 21:57:12 -0500
Subject: Building on Mac OS X 10.5.6
In-Reply-To: <24622727-E319-4BB0-81A5-90512ADAB633@osl.iu.edu>
References: <F1710E97-C3D7-41AE-BDEF-DF9BC3520E0D@osl.iu.edu>	<49821A83.7060106@intricatesoftware.com>
	<24622727-E319-4BB0-81A5-90512ADAB633@osl.iu.edu>
Message-ID: <49826C88.7060508@intricatesoftware.com>

Hi Ronald,

We're having a bit of trouble with the bsd-port forest right now.
I think some recent pushes to the tree have interfered with the
OS X build but due to some repository corruption, I can't get diffs
of the recent changes back from mercurial. Once the corruption
is cleared we should be able to fix this up easily enough.

LC_ALL=C will be needed if LC_ALL is set in the environment to
something different.

DEVTOOLS_PATH is the path to development tools that don't come
installed with the base system. On OS X nothing extra is needed
to build OpenJDK/bsd-port. For FreeBSD and OpenBSD it points to
/usr/local/bin to get things like zip, unzip, etc. If you need
to set it for OS X then something needs to be fixed.

Can you show the last 50 or so lines of the build failure when
DEVTOOLS_PATH is not set on your OS X build?

Thanks,
-Kurt

Ronald Garcia wrote:
> Hi Kurt,
> 
> Thanks for the fast reply.  I just ran hg fpull and hg fupdate.  make  
> still seems to need DEVTOOLS_PATH (things are still building, so I  
> don't know yet if I also need ALT_CUPS_HEADERS_PATH).  I also had to  
> add LC_ALL=C (I must not have had it set last time).
> Also, as it turns out, I still needed my changes to the splashscreen  
> Makefile for building to succeed.
> 
> 
> So my current build process is using the following command line:
> 
> make \
> ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 \
> ALT_BINARY_PLUGS_PATH=/usr/local/lib/jdk-7-icedtea-plugs \
> ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \
> ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \
> ANT_HOME=/usr/share/ant \
> NO_DOCS=true \
> HOTSPOT_BUILD_JOBS=1 \
> DEVTOOLS_PATH=/usr/bin \
> LC_ALL=C \
> LANG=C
> 
> and a modified makefile for splashscreen
> 
> Cheers,
> ron
> 
> 
> 
> On Jan 29, 2009, at 3:07 PM, Kurt Miller wrote:
> 
>>> My question is this:  Am I missing something in the build process  
>>> such
>>> that DEVTOOLS_PATH isn't getting set on its own and that is causing
>>> ICONV to not get included on the build path?
>> I recently corrected several path defaults, including the ones you
>> are hitting now. Please retry after updating your tree (hg fpull,
>> hg fupdate). You should no longer need to set ALT_CUPS_HEADERS_PATH
>> and DEVTOOLS_PATH on OS X.
> 
> 



From garcia at osl.iu.edu  Fri Jan 30 10:48:41 2009
From: garcia at osl.iu.edu (Ronald Garcia)
Date: Fri, 30 Jan 2009 12:48:41 -0600
Subject: Building on Mac OS X 10.5.6
In-Reply-To: <49826C88.7060508@intricatesoftware.com>
References: <F1710E97-C3D7-41AE-BDEF-DF9BC3520E0D@osl.iu.edu>	<49821A83.7060106@intricatesoftware.com>
	<24622727-E319-4BB0-81A5-90512ADAB633@osl.iu.edu>
	<49826C88.7060508@intricatesoftware.com>
Message-ID: <E419ACD5-0F71-401D-8D69-05D0BAA626C2@osl.iu.edu>

Hi Kurt,


On Jan 29, 2009, at 8:57 PM, Kurt Miller wrote:

> We're having a bit of trouble with the bsd-port forest right now.
> I think some recent pushes to the tree have interfered with the
> OS X build but due to some repository corruption, I can't get diffs
> of the recent changes back from mercurial. Once the corruption
> is cleared we should be able to fix this up easily enough.

Good to know, thanks.

>
>
> LC_ALL=C will be needed if LC_ALL is set in the environment to
> something different.
Roger.

>
>
> DEVTOOLS_PATH is the path to development tools that don't come
> installed with the base system. On OS X nothing extra is needed
> to build OpenJDK/bsd-port. For FreeBSD and OpenBSD it points to
> /usr/local/bin to get things like zip, unzip, etc. If you need
> to set it for OS X then something needs to be fixed.
>
> Can you show the last 50 or so lines of the build failure when
> DEVTOOLS_PATH is not set on your OS X build?
>

Sure.  I've attached a file containing the output of my make command  
(compilation didn't get very far before dying).

Cheers,
ron

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: output.txt
Url: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090130/d68baaa4/output.txt 
-------------- next part --------------


From kurt at intricatesoftware.com  Fri Jan 30 11:42:37 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Fri, 30 Jan 2009 14:42:37 -0500
Subject: Building on Mac OS X 10.5.6
In-Reply-To: <E419ACD5-0F71-401D-8D69-05D0BAA626C2@osl.iu.edu>
References: <F1710E97-C3D7-41AE-BDEF-DF9BC3520E0D@osl.iu.edu>	<49821A83.7060106@intricatesoftware.com>	<24622727-E319-4BB0-81A5-90512ADAB633@osl.iu.edu>	<49826C88.7060508@intricatesoftware.com>
	<E419ACD5-0F71-401D-8D69-05D0BAA626C2@osl.iu.edu>
Message-ID: <4983582D.30603@intricatesoftware.com>

Hi Ron,

Ronald Garcia wrote:
>> DEVTOOLS_PATH is the path to development tools that don't come
>> installed with the base system. On OS X nothing extra is needed
>> to build OpenJDK/bsd-port. For FreeBSD and OpenBSD it points to
>> /usr/local/bin to get things like zip, unzip, etc. If you need
>> to set it for OS X then something needs to be fixed.
>>
>> Can you show the last 50 or so lines of the build failure when
>> DEVTOOLS_PATH is not set on your OS X build?
>>
> 
> Sure.  I've attached a file containing the output of my make command
> (compilation didn't get very far before dying).

Thanks that helped. I see the issue with DEVTOOLS_PATH on OS X and will
fix it as soon as the forest is cleared of the corruption.

-Kurt


From christos at zoulas.com  Fri Jan 30 11:58:33 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 30 Jan 2009 14:58:33 -0500
Subject: Building on Mac OS X 10.5.6
In-Reply-To: <4983582D.30603@intricatesoftware.com>
	from Kurt Miller (Jan 30,  2:42pm)
Message-ID: <20090130195833.AD81D5654E@rebar.astron.com>

On Jan 30,  2:42pm, kurt at intricatesoftware.com (Kurt Miller) wrote:
-- Subject: Re: Building on Mac OS X 10.5.6

| Thanks that helped. I see the issue with DEVTOOLS_PATH on OS X and will
| fix it as soon as the forest is cleared of the corruption.

Any updates on that (and sorry for the trouble I caused)?

christos


From garcia at osl.iu.edu  Fri Jan 30 12:13:24 2009
From: garcia at osl.iu.edu (Ronald Garcia)
Date: Fri, 30 Jan 2009 14:13:24 -0600
Subject: Building on Mac OS X 10.5.6
In-Reply-To: <4983582D.30603@intricatesoftware.com>
References: <F1710E97-C3D7-41AE-BDEF-DF9BC3520E0D@osl.iu.edu>	<49821A83.7060106@intricatesoftware.com>	<24622727-E319-4BB0-81A5-90512ADAB633@osl.iu.edu>	<49826C88.7060508@intricatesoftware.com>
	<E419ACD5-0F71-401D-8D69-05D0BAA626C2@osl.iu.edu>
	<4983582D.30603@intricatesoftware.com>
Message-ID: <12B5F108-AF49-4296-8034-F7F60CEA4782@osl.iu.edu>

Great, thanks!

ron

On Jan 30, 2009, at 1:42 PM, Kurt Miller wrote:

> Hi Ron,
>
> Ronald Garcia wrote:
>>> Can you show the last 50 or so lines of the build failure when
>>> DEVTOOLS_PATH is not set on your OS X build?
>>>
>>
>> Sure.  I've attached a file containing the output of my make command
>> (compilation didn't get very far before dying).
>
> Thanks that helped. I see the issue with DEVTOOLS_PATH on OS X and  
> will
> fix it as soon as the forest is cleared of the corruption.
>
> -Kurt



From charles.nutter at sun.com  Fri Jan 30 12:30:29 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Fri, 30 Jan 2009 14:30:29 -0600
Subject: Step-by-step OpenJDK on OS X?
Message-ID: <49836365.6070206@sun.com>

I've read through some of the backthreads and there's a lot of noise 
about getting OpenJDK to build, having this issue, applying that patch. 
I'm wondering what the bottom line is today:

- Is it possible to build OpenJDK on OS X right now? Which 
versions/branches/etc?
- Has anyone aggregated the instructions required to do so yet? I mostly 
got an older revision to build using Landon Fuller's walkthrough, but 
that's pretty dated now.

Is there a wiki for this where we could collaborate on a 
walkthrough/tutorial? I'm eager to get a build going so I can start 
contributing to MLVM without my Linux box or a Linux VM.

- Charlie


From brian at experts-exchange.com  Fri Jan 30 13:11:16 2009
From: brian at experts-exchange.com (Brian Gardner)
Date: Fri, 30 Jan 2009 13:11:16 -0800
Subject: created an patch and install process for openjdk6
Message-ID: <49836CF4.40803@experts-exchange.com>

Hello fellow BSD lovers,
I've created a patch process for patching openjdk6 for BSD (FreeBSD 
specifically), although I tried to keep all BSD versions in mind when 
creating my patch.
http://beta.experts-exchange.com/articles/OS/Unix/BSD/Patch-for-OpenJDK6-on-BSD.html#top 


Welcome to OpenJDK6 on BSD

First let me start with a little background on why I chose to port 
openjdk6, and then I'll discuss the process I took to do it.  I work for 
Experts Exchange recently we decided to move from Linux to FreeBSD.  
This decision came after a comprehensive test involving Linux, FreeBSD, 
and Solaris 10.  FreeBSD blew the others away doubling the performance 
of Linux and outperforming Solaris 10 by a significant margin as well.  
We have come across several issues with the port java/jdk16, including 
lack of jmap functionality to track down memory errors and instability 
running the CMS garbage collector with a heap over 2G.  I created the a 
patch to bring jmap functionality to java/jdk16.  My next task was to 
begin hardening the VM, however it hardly makes sense to work on 
java/jdk16, because it's missing lots of bugs fixes from sun.  openjdk7 
looked like the next choice to try and I compiled it up and gave it a 
try, however a third party library/software I was using didn't work and 
upon talking with terracotta developers they had no plans to support 
openjdk7 in the future.  I researched what exactly openjdk6 was and 
decided to give it a try.


How did I perform the Port

I started by duplicating jdk6 to bsd-port6.  Then I take the difference 
between jdk7 and bsd-port and import them.  I had trouble using patch 
-Nu jdk7 bsd-port because there were new files that contained long lines 
that patch complained about.  I whipped up a quick perl script to 
compare the directories and create the 
jdk7_bsd_changes_20090126.newfiles and jdk7_bsd_changes_20090126.patches 
directories.  Any file the was brand new to bsd-port was copied into 
jdk7_bsd_changes_20090126.newfiles to avoid the patch issue with long 
lines.  jdk7_bsd_changes_20090126.patches contains a separate patch for 
each file the was changed between jdk7 and bsd-port.  Not all of these 
patches applied cleanly so I then went through about 40 .rej files and 
applied the patches by hand, keeping track of the changes.  When 
compiling I released the build structure had changed between jdk6 and 
jdk7 and bsd-port6/hotspot/make/bsd/ had to be moved to 
bsd-port6/hotspot/build/bsd.  Makefiles also had to be patched to 
complete the change.  custom-patches contains these patches.


Applying the patch.
*) run import_patch.pl
  - download jdk6 using mercurial to _jdk6
  - dupicate _jdk6 to bsd-port6
  - apply jdk7-bsd-changes-20090126
  - apply custom-patches
*) now compile, I've included a build_bsd-port6.sh script that I use to 
start compiling



Notes of Custom Patches

COPIED FROM bsd-port to bsd-port6
jdk/src/solaris/native/java/io/UnixFileSystem_md.c
jdk/src/solaris/classes/java/lang/UNIXProcess.java.bsd


HAND PATCHED
jdk/src/solaris/bin/java_md.c
jdk/src/share/classes/sun/tools/jar/Main.java
jdk/make/sun/awt/Makefile
jdk/make/tools/freetypecheck/Makefile
jdk/src/share/bin/java.c
jdk/src/share/native/common/check_code.c
jdk/src/share/transport/socket/socketTransport.c
jdk/src/solaris/native/java/lang/UNIXProcess_md.c
jdk/src/solaris/native/sun/nio/ch/Net.c
hotspot/src/share/vm/runtime/os.cpp
hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp
hotspot/src/share/vm/utilities/macros.hpp
hotspot/src/share/vm/utilities/vmError.cpp
hotspot/src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
hotspot/src/share/vm/gc_implementation/includeDB_gc_parNew
jdk/make/common/internal/BinaryPlugs.gmk
jdk/make/common/shared/Platform.gmk
hotspot/src/cpu/x86/vm/stubGenerator_x86_64.cpp
hotspot/src/cpu/x86/vm/x86_32.ad
hotspot/src/cpu/x86/vm/interpreterRT_x86_32.cpp
hotspot/src/cpu/x86/vm/runtime_x86_32.cpp
jdk/src/share/classes/java/lang/ProcessBuilder.java

MAKEFILES
mv bsd-port6/hotspot/make/bsd bsd-port6/hotspot/build/bsd

NOTES
jdk/src/share/bin/java.c - was hand patched, however I wasn't able to 
test compiling on Mac OS X, and I worry it won't compile


From gnu_andrew at member.fsf.org  Fri Jan 30 13:26:29 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 30 Jan 2009 21:26:29 +0000
Subject: created an patch and install process for openjdk6
In-Reply-To: <49836CF4.40803@experts-exchange.com>
References: <49836CF4.40803@experts-exchange.com>
Message-ID: <17c6771e0901301326l16ddf102xee03a4a6a09e1168@mail.gmail.com>

2009/1/30 Brian Gardner <brian at experts-exchange.com>:
> Hello fellow BSD lovers,
> I've created a patch process for patching openjdk6 for BSD (FreeBSD
> specifically), although I tried to keep all BSD versions in mind when
> creating my patch.
> http://beta.experts-exchange.com/articles/OS/Unix/BSD/Patch-for-OpenJDK6-on-BSD.html#top
>
>
> Welcome to OpenJDK6 on BSD
>
> First let me start with a little background on why I chose to port
> openjdk6, and then I'll discuss the process I took to do it.  I work for
> Experts Exchange recently we decided to move from Linux to FreeBSD.
> This decision came after a comprehensive test involving Linux, FreeBSD,
> and Solaris 10.  FreeBSD blew the others away doubling the performance
> of Linux and outperforming Solaris 10 by a significant margin as well.
> We have come across several issues with the port java/jdk16, including
> lack of jmap functionality to track down memory errors and instability
> running the CMS garbage collector with a heap over 2G.  I created the a
> patch to bring jmap functionality to java/jdk16.  My next task was to
> begin hardening the VM, however it hardly makes sense to work on
> java/jdk16, because it's missing lots of bugs fixes from sun.  openjdk7
> looked like the next choice to try and I compiled it up and gave it a
> try, however a third party library/software I was using didn't work and
> upon talking with terracotta developers they had no plans to support
> openjdk7 in the future.  I researched what exactly openjdk6 was and
> decided to give it a try.
>
>
> How did I perform the Port
>
> I started by duplicating jdk6 to bsd-port6.  Then I take the difference
> between jdk7 and bsd-port and import them.  I had trouble using patch
> -Nu jdk7 bsd-port because there were new files that contained long lines
> that patch complained about.  I whipped up a quick perl script to
> compare the directories and create the
> jdk7_bsd_changes_20090126.newfiles and jdk7_bsd_changes_20090126.patches
> directories.  Any file the was brand new to bsd-port was copied into
> jdk7_bsd_changes_20090126.newfiles to avoid the patch issue with long
> lines.  jdk7_bsd_changes_20090126.patches contains a separate patch for
> each file the was changed between jdk7 and bsd-port.  Not all of these
> patches applied cleanly so I then went through about 40 .rej files and
> applied the patches by hand, keeping track of the changes.  When
> compiling I released the build structure had changed between jdk6 and
> jdk7 and bsd-port6/hotspot/make/bsd/ had to be moved to
> bsd-port6/hotspot/build/bsd.  Makefiles also had to be patched to
> complete the change.  custom-patches contains these patches.
>
>
> Applying the patch.
> *) run import_patch.pl
>  - download jdk6 using mercurial to _jdk6
>  - dupicate _jdk6 to bsd-port6
>  - apply jdk7-bsd-changes-20090126
>  - apply custom-patches
> *) now compile, I've included a build_bsd-port6.sh script that I use to
> start compiling
>
>
>
> Notes of Custom Patches
>
> COPIED FROM bsd-port to bsd-port6
> jdk/src/solaris/native/java/io/UnixFileSystem_md.c
> jdk/src/solaris/classes/java/lang/UNIXProcess.java.bsd
>
>
> HAND PATCHED
> jdk/src/solaris/bin/java_md.c
> jdk/src/share/classes/sun/tools/jar/Main.java
> jdk/make/sun/awt/Makefile
> jdk/make/tools/freetypecheck/Makefile
> jdk/src/share/bin/java.c
> jdk/src/share/native/common/check_code.c
> jdk/src/share/transport/socket/socketTransport.c
> jdk/src/solaris/native/java/lang/UNIXProcess_md.c
> jdk/src/solaris/native/sun/nio/ch/Net.c
> hotspot/src/share/vm/runtime/os.cpp
> hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp
> hotspot/src/share/vm/utilities/macros.hpp
> hotspot/src/share/vm/utilities/vmError.cpp
> hotspot/src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
> hotspot/src/share/vm/gc_implementation/includeDB_gc_parNew
> jdk/make/common/internal/BinaryPlugs.gmk
> jdk/make/common/shared/Platform.gmk
> hotspot/src/cpu/x86/vm/stubGenerator_x86_64.cpp
> hotspot/src/cpu/x86/vm/x86_32.ad
> hotspot/src/cpu/x86/vm/interpreterRT_x86_32.cpp
> hotspot/src/cpu/x86/vm/runtime_x86_32.cpp
> jdk/src/share/classes/java/lang/ProcessBuilder.java
>
> MAKEFILES
> mv bsd-port6/hotspot/make/bsd bsd-port6/hotspot/build/bsd
>
> NOTES
> jdk/src/share/bin/java.c - was hand patched, however I wasn't able to
> test compiling on Mac OS X, and I worry it won't compile
>
>

This is good to see.  My personal thoughts for a while have been that
the BSD port would work better as a patchset rather than a completely
separate tree, and the small amount of affected files here backs that
up.  I'll try and look at it in more detail at some point.
-- 
Andrew :-)

IcedTea/OpenJDK Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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

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


From Xiaobin.Lu at Sun.COM  Fri Jan 30 13:45:05 2009
From: Xiaobin.Lu at Sun.COM (Xiaobin Lu)
Date: Fri, 30 Jan 2009 13:45:05 -0800
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <49836365.6070206@sun.com>
References: <49836365.6070206@sun.com>
Message-ID: <498374E1.5030709@Sun.COM>

Hi Charlie,

The following page is perhaps all  you need.

http://landonf.bikemonkey.org/code/java/SoyLatte_Meets_OpenJDK.20080819.html

-Xiaobin

On 01/30/09 12:30, Charles Oliver Nutter wrote:
> I've read through some of the backthreads and there's a lot of noise 
> about getting OpenJDK to build, having this issue, applying that patch. 
> I'm wondering what the bottom line is today:
>
> - Is it possible to build OpenJDK on OS X right now? Which 
> versions/branches/etc?
> - Has anyone aggregated the instructions required to do so yet? I mostly 
> got an older revision to build using Landon Fuller's walkthrough, but 
> that's pretty dated now.
>
> Is there a wiki for this where we could collaborate on a 
> walkthrough/tutorial? I'm eager to get a build going so I can start 
> contributing to MLVM without my Linux box or a Linux VM.
>
> - Charlie
>
>   



From charles.nutter at sun.com  Fri Jan 30 13:49:03 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Fri, 30 Jan 2009 15:49:03 -0600
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <498374E1.5030709@Sun.COM>
References: <49836365.6070206@sun.com> <498374E1.5030709@Sun.COM>
Message-ID: <498375CF.3000403@sun.com>

Is this enough to build against, say, b44? I'm starting the process now...

Xiaobin Lu wrote:
> Hi Charlie,
> 
> The following page is perhaps all  you need.
> 
> http://landonf.bikemonkey.org/code/java/SoyLatte_Meets_OpenJDK.20080819.html 
> 
> 
> -Xiaobin
> 
> On 01/30/09 12:30, Charles Oliver Nutter wrote:
>> I've read through some of the backthreads and there's a lot of noise 
>> about getting OpenJDK to build, having this issue, applying that 
>> patch. I'm wondering what the bottom line is today:
>>
>> - Is it possible to build OpenJDK on OS X right now? Which 
>> versions/branches/etc?
>> - Has anyone aggregated the instructions required to do so yet? I 
>> mostly got an older revision to build using Landon Fuller's 
>> walkthrough, but that's pretty dated now.
>>
>> Is there a wiki for this where we could collaborate on a 
>> walkthrough/tutorial? I'm eager to get a build going so I can start 
>> contributing to MLVM without my Linux box or a Linux VM.
>>
>> - Charlie
>>
>>   
> 



From Xiaobin.Lu at Sun.COM  Fri Jan 30 14:12:07 2009
From: Xiaobin.Lu at Sun.COM (Xiaobin Lu)
Date: Fri, 30 Jan 2009 14:12:07 -0800
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <498375CF.3000403@sun.com>
References: <49836365.6070206@sun.com> <498374E1.5030709@Sun.COM>
	<498375CF.3000403@sun.com>
Message-ID: <49837B37.7010408@Sun.COM>

On 01/30/09 13:49, Charles Oliver Nutter wrote:
> Is this enough to build against, say, b44? I'm starting the process 
> now...
I know the BSD porting repository syncs with our open JDK tree every 
once in a while, so if OpenJDK is at b44, yes, you are building against b44.

-Xiaobin
>
> Xiaobin Lu wrote:
>> Hi Charlie,
>>
>> The following page is perhaps all  you need.
>>
>> http://landonf.bikemonkey.org/code/java/SoyLatte_Meets_OpenJDK.20080819.html 
>>
>>
>> -Xiaobin
>>
>> On 01/30/09 12:30, Charles Oliver Nutter wrote:
>>> I've read through some of the backthreads and there's a lot of noise 
>>> about getting OpenJDK to build, having this issue, applying that 
>>> patch. I'm wondering what the bottom line is today:
>>>
>>> - Is it possible to build OpenJDK on OS X right now? Which 
>>> versions/branches/etc?
>>> - Has anyone aggregated the instructions required to do so yet? I 
>>> mostly got an older revision to build using Landon Fuller's 
>>> walkthrough, but that's pretty dated now.
>>>
>>> Is there a wiki for this where we could collaborate on a 
>>> walkthrough/tutorial? I'm eager to get a build going so I can start 
>>> contributing to MLVM without my Linux box or a Linux VM.
>>>
>>> - Charlie
>>>
>>>   
>>
>



From benjamin.john.evans at googlemail.com  Fri Jan 30 14:15:04 2009
From: benjamin.john.evans at googlemail.com (Ben Evans)
Date: Fri, 30 Jan 2009 22:15:04 +0000
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <49836365.6070206@sun.com>
References: <49836365.6070206@sun.com>
Message-ID: <38a53eb30901301415u232e8700p15b9faa2b94c5d0f@mail.gmail.com>

Hi Charlie,

My understanding is that the current bsd-port is still broken for OS X and
that we expect it to be unbroken sometime soon.

I documented the last working build I had at:

http://boxcatjunction.blogspot.com/2008/12/some-updates-to-build-process.html

If the current bsd-port tree is in a reasonable shape and will build, I
would be very up for helping get the latest MLVM patches applying to it and
building on OS X.

Thanks,

Ben

On Fri, Jan 30, 2009 at 8:30 PM, Charles Oliver Nutter <
charles.nutter at sun.com> wrote:

> I've read through some of the backthreads and there's a lot of noise
> about getting OpenJDK to build, having this issue, applying that patch.
> I'm wondering what the bottom line is today:
>
> - Is it possible to build OpenJDK on OS X right now? Which
> versions/branches/etc?
> - Has anyone aggregated the instructions required to do so yet? I mostly
> got an older revision to build using Landon Fuller's walkthrough, but
> that's pretty dated now.
>
> Is there a wiki for this where we could collaborate on a
> walkthrough/tutorial? I'm eager to get a build going so I can start
> contributing to MLVM without my Linux box or a Linux VM.
>
> - Charlie
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090130/b0a5f24c/attachment.html 

From kurt at intricatesoftware.com  Fri Jan 30 14:55:26 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Fri, 30 Jan 2009 17:55:26 -0500
Subject: Building on Mac OS X 10.5.6
In-Reply-To: <20090130195833.AD81D5654E@rebar.astron.com>
References: <20090130195833.AD81D5654E@rebar.astron.com>
Message-ID: <4983855E.8090405@intricatesoftware.com>

Christos Zoulas wrote:
> On Jan 30,  2:42pm, kurt at intricatesoftware.com (Kurt Miller) wrote:
> -- Subject: Re: Building on Mac OS X 10.5.6
> 
> | Thanks that helped. I see the issue with DEVTOOLS_PATH on OS X and will
> | fix it as soon as the forest is cleared of the corruption.
> 
> Any updates on that (and sorry for the trouble I caused)?

No updates. Hey you didn't know that mercurial had a bug with 64 bit
time_t. Don't feel bad it could have happened to anyone.

The only thing I've found that might work is to use 'hg rollback'
on Sun's server to revert the last push. We need help from Sun to
clear the problem... Help Sun.

-Kurt


From garcia at osl.iu.edu  Fri Jan 30 15:56:51 2009
From: garcia at osl.iu.edu (Ronald Garcia)
Date: Fri, 30 Jan 2009 17:56:51 -0600
Subject: portability beyond *BSD
Message-ID: <D2119628-700C-49DF-A610-F84A2D1D7838@osl.iu.edu>

Hi all,

Does the BSD port of openjdk also compile under linux?  I under the  
impression that the eventual goal is to merge the bsd-port-dev  
repository into the mainline release of openjdk, but I wonder if in  
the meantime it retains portability to the old supported platforms as  
support for BSD is added?

Thanks,
ron



From mvfranz at gmail.com  Fri Jan 30 16:10:26 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Fri, 30 Jan 2009 19:10:26 -0500
Subject: created an patch and install process for openjdk6
In-Reply-To: <49836CF4.40803@experts-exchange.com>
References: <49836CF4.40803@experts-exchange.com>
Message-ID: <fee4d890901301610o449cde11mc2f655d1d8d6e61@mail.gmail.com>

Brian,

This is great!  I have tried a similar process to add bsd support into
JDK6.  The changes between the jdk sub-project is the biggest issue I have
had.

I downloaded  your zip and ran the import_patch.pl .  There were a lot of
failed patches.

I tried to build the way I normally do for OpenJDK7, but that failed.
Probably some of the failed patches are preventing the build from starting.

I am using OS X 10.5.6

Keep up the good work.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090130/c1f3ed94/attachment.html 

From christos at zoulas.com  Fri Jan 30 16:29:25 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 30 Jan 2009 19:29:25 -0500
Subject: portability beyond *BSD
In-Reply-To: <D2119628-700C-49DF-A610-F84A2D1D7838@osl.iu.edu>
	from Ronald Garcia (Jan 30,  5:56pm)
Message-ID: <20090131002925.E0F5C5654E@rebar.astron.com>

On Jan 30,  5:56pm, garcia at osl.iu.edu (Ronald Garcia) wrote:
-- Subject: portability beyond *BSD

| Hi all,
| 
| Does the BSD port of openjdk also compile under linux?  I under the  
| impression that the eventual goal is to merge the bsd-port-dev  
| repository into the mainline release of openjdk, but I wonder if in  
| the meantime it retains portability to the old supported platforms as  
| support for BSD is added?
| 

It should, all the patches are done in a portable way.

christos


From kurt at intricatesoftware.com  Sat Jan 31 05:15:05 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Sat, 31 Jan 2009 08:15:05 -0500
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <38a53eb30901301415u232e8700p15b9faa2b94c5d0f@mail.gmail.com>
References: <49836365.6070206@sun.com>
	<38a53eb30901301415u232e8700p15b9faa2b94c5d0f@mail.gmail.com>
Message-ID: <49844ED9.4070007@intricatesoftware.com>

Ben Evans wrote:
> Hi Charlie,
> 
> My understanding is that the current bsd-port is still broken for OS X
> and that we expect it to be unbroken sometime soon.

To unbreak the OS X build you can issue the following commands which
will revert the minor breakage in the tree right now. But first enable
the mq extension in ~/.hgrc to enable the hg strip command:

[extensions]
hgext.mq =

$ cd bsd-port
$ cd hotspot
$ hg strip 32826d5f1894
$ cd ../jdk
$ hg strip 97139295a172

Temporally DEVTOOLS_PATH needs to be set to point an existing directory.
It doesn't matter what dir since OS X doesn't use it, just something to
satisfy the sanity check.

> I documented the last working build I had at:
> 
> http://boxcatjunction.blogspot.com/2008/12/some-updates-to-build-process.html
> 
> If the current bsd-port tree is in a reasonable shape and will build, I
> would be very up for helping get the latest MLVM patches applying to it
> and building on OS X.
> 
> Thanks,
> 
> Ben
> 
> On Fri, Jan 30, 2009 at 8:30 PM, Charles Oliver Nutter
> <charles.nutter at sun.com <mailto:charles.nutter at sun.com>> wrote:
> 
>     I've read through some of the backthreads and there's a lot of noise
>     about getting OpenJDK to build, having this issue, applying that patch.
>     I'm wondering what the bottom line is today:
> 
>     - Is it possible to build OpenJDK on OS X right now? Which
>     versions/branches/etc?
>     - Has anyone aggregated the instructions required to do so yet? I mostly
>     got an older revision to build using Landon Fuller's walkthrough, but
>     that's pretty dated now.
> 
>     Is there a wiki for this where we could collaborate on a
>     walkthrough/tutorial? I'm eager to get a build going so I can start
>     contributing to MLVM without my Linux box or a Linux VM.
> 
>     - Charlie
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 



From kurt at intricatesoftware.com  Sat Jan 31 06:17:12 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Sat, 31 Jan 2009 09:17:12 -0500
Subject: created an patch and install process for openjdk6
In-Reply-To: <49836CF4.40803@experts-exchange.com>
References: <49836CF4.40803@experts-exchange.com>
Message-ID: <49845D68.70207@intricatesoftware.com>

Hi Brian,

Terrific! You've accomplish a lot in a short period of time. I haven't
the opportunity to try this yet, but I read the method you followed and
have some comments below.

Brian Gardner wrote:
> How did I perform the Port
> 
> I started by duplicating jdk6 to bsd-port6.  Then I take the difference 
> between jdk7 and bsd-port and import them.  I had trouble using patch 
> -Nu jdk7 bsd-port because there were new files that contained long lines 
> that patch complained about.  I whipped up a quick perl script to 
> compare the directories and create the 
> jdk7_bsd_changes_20090126.newfiles and jdk7_bsd_changes_20090126.patches 
> directories.

Sounds good.

>  Any file the was brand new to bsd-port was copied into 
> jdk7_bsd_changes_20090126.newfiles to avoid the patch issue with long 
> lines.

This part is going to cause some issues. Coping the bsd src back from
openjdk7 to openjdk6 is bad. It will be mixing new openjdk with old.
I'll explain more about how to do this correctly below.

>  jdk7_bsd_changes_20090126.patches contains a separate patch for 
> each file the was changed between jdk7 and bsd-port.  Not all of these 
> patches applied cleanly so I then went through about 40 .rej files and 
> applied the patches by hand, keeping track of the changes.  When 
> compiling I released the build structure had changed between jdk6 and 
> jdk7 and bsd-port6/hotspot/make/bsd/ had to be moved to 
> bsd-port6/hotspot/build/bsd.  Makefiles also had to be patched to 
> complete the change.  custom-patches contains these patches.

Generally speaking the process you followed for patches to existing
files is good. i.e. take the diff of bsd-port and jdk7 forests, then
apply that back to jdk6, resolve conflicts and moved directories by
hand.

For new bsd files the process needs to follow a more indirect path
to ensure that the resulting bsd files are in sync with openjdk6.

First let me explain how those bsd files were created. Going back
to 1.4 and 1.5 jdks we used a mix of Linux and Solaris as the basis
for creating the bsd source. However with openjdk7 and the 1.6 port
we switched to only using Linux as basis for the bsd source. We did this
for a few reasons but I digress. The important point is that the new
files for the bsd port are based almost exclusively on the linux src.

The process to move 'new file' bsd support back to openjdk6 (or forward
to openjdk8) is as follows. Create a diff of the new bsd file against
the corresponding linux file from which it was created in bsd-port.
Then in openjdk6 copy the linux file to bsd directory/name as the
starting point and apply the diff, resolve conflicts by hand.

It is important to follow this process especially for hotspot since
subtable breakage can be introduced by just coping back a subset of
openjdk7 code into openjdk6.

Here is a list of the linux directories and files that that were
copied to start the basis of bsd files:

COPYDIRS=       hotspot/src/os/linux/launcher \
                hotspot/src/os/linux/vm \
                hotspot/src/os_cpu/linux_x86/vm \
                hotspot/make/linux \
                hotspot/make/linux/makefiles \
                jdk/src/linux/doc/man

COPYFILES=      corba/make/common/Defs-linux.gmk \
                corba/make/common/shared/Defs-linux.gmk \
                jdk/make/common/Defs-linux.gmk \
                jdk/make/common/shared/Defs-linux.gmk \
                jdk/make/java/nio/mapfile-linux \

jdk/make/netbeans/common/architectures/name-Linux.properties \
                jdk/make/sun/awt/mapfile-vers-linux \
                jdk/make/tools/sharing/classlist.linux \
                jdk/src/solaris/classes/java/lang/UNIXProcess.java.linux \

jdk/src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties \

jdk/src/solaris/classes/sun/tools/attach/LinuxAttachProvider.java \
                jdk/src/solaris/hpi/include/largefile_linux.h

And the one Solaris file used as a starting point is:

jdk/src/solaris/hpi/native_threads/src/threads_solaris.c

Regards,
-Kurt


From benjamin.john.evans at googlemail.com  Sat Jan 31 10:31:27 2009
From: benjamin.john.evans at googlemail.com (Ben Evans)
Date: Sat, 31 Jan 2009 18:31:27 +0000
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <49844ED9.4070007@intricatesoftware.com>
References: <49836365.6070206@sun.com>
	<38a53eb30901301415u232e8700p15b9faa2b94c5d0f@mail.gmail.com>
	<49844ED9.4070007@intricatesoftware.com>
Message-ID: <38a53eb30901311031i2354b90eo4e37fc80b69f63db@mail.gmail.com>

Hi Kurt,

On Sat, Jan 31, 2009 at 1:15 PM, Kurt Miller <kurt at intricatesoftware.com>wrote:

> Ben Evans wrote:
> > Hi Charlie,
> >
> > My understanding is that the current bsd-port is still broken for OS X
> > and that we expect it to be unbroken sometime soon.
>
> To unbreak the OS X build you can issue the following commands which
> will revert the minor breakage in the tree right now. But first enable
> the mq extension in ~/.hgrc to enable the hg strip command:
>
> [extensions]
> hgext.mq =
>
> $ cd bsd-port
> $ cd hotspot
> $ hg strip 32826d5f1894
> $ cd ../jdk
> $ hg strip 97139295a172
>
> Temporally DEVTOOLS_PATH needs to be set to point an existing directory.
> It doesn't matter what dir since OS X doesn't use it, just something to
> satisfy the sanity check.
>

OK.

I'm having trouble with the ALT_JDK_IMPORT_PATH sanity check. My make line
seems basically identical to yours - except that you don't set
ALT_JDK_IMPORT_PATH.

If I try building without that set, I get tons of warnings and then fail
immediately with this:

# Running javac:
Check_ALT_JDK_IMPORT_PATH/bin/javac -J-XX:ThreadStackSize=768 -J-client
-J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -source 1.5
-target 5 -encoding ascii -classpath
/usr/local/soylatte16-i386-1.0.3/lib/tools.jar -sourcepath
/Users/boxcat/projects/jdk7-2009-01-30/sources/build/bsd-i586/corba/gensrc:../../../src/solaris/classes:../../../src/share/classes
-d
/Users/boxcat/projects/jdk7-2009-01-30/sources/build/bsd-i586/corba/classes
@/Users/boxcat/projects/jdk7-2009-01-30/sources/build/bsd-i586/corba/tmp/sun/javax.transaction.xa/.classes.list
/bin/sh: Check_ALT_JDK_IMPORT_PATH/bin/javac: No such file or directory
make[4]: *** [.compile.classlist] Error 127

Could you post the output of set in your build shell so I can try and spot
any differences in the way our environments are setup?

Thanks,

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090131/117f2f75/attachment.html 

From charles.nutter at sun.com  Sat Jan 31 11:05:29 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Sat, 31 Jan 2009 13:05:29 -0600
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <498374E1.5030709@Sun.COM>
References: <49836365.6070206@sun.com> <498374E1.5030709@Sun.COM>
Message-ID: <4984A0F9.9060408@sun.com>

Xiaobin Lu wrote:
> Hi Charlie,
> 
> The following page is perhaps all  you need.
> 
> http://landonf.bikemonkey.org/code/java/SoyLatte_Meets_OpenJDK.20080819.html 

So far I'm not even getting into the build process following Landon's 
instructions:

$ make ALT_BOOTDIR=/usr/local/soylatte-amd64-1.0.3 
ALT_BINARY_PLUGS_PATH=$HOME/jdk-7-icedtea-plugs 
ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include 
ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib ALT_CUPS_HEADERS_PATH=/usr/include 
ANT_HOME=/usr/share/ant NO_DOCS=true HOTSPOT_BUILD_JOBS=1

Control bsd i586 1.7.0-internal all build started:
df: negative filesystem block count/size from fs /Volumes/jruby
df: negative filesystem block count/size from fs /Volumes/jruby
df: negative filesystem block count/size from fs /Volumes/jruby
df: negative filesystem block count/size from fs /Volumes/jruby
/bin/sh: line 0: [: /bin/sh:: integer expression expected
/bin/sh: line 0: [: /bin/sh:: integer expression expected

Build Machine Information:
    build machine = cnutter.local

Build Directory Structure:
    CWD = /Users/headius/projects/openjdk
    TOPDIR = .
    CONTROL_TOPDIR = .
    LANGTOOLS_TOPDIR = ./langtools
    JAXP_TOPDIR = ./jaxp
    JAXWS_TOPDIR = ./jaxws
    CORBA_TOPDIR = ./corba
    HOTSPOT_TOPDIR = ./hotspot
    JDK_TOPDIR = ./jdk

Build Directives:
    BUILD_LANGTOOLS = true
    BUILD_JAXP = true
    BUILD_JAXWS = true
    BUILD_CORBA = true
    BUILD_HOTSPOT = true
    BUILD_JDK    = true

Hotspot Settings: \n      HOTSPOT_BUILD_JOBS  = 1 \n 
HOTSPOT_OUTPUTDIR   = 
/Users/headius/projects/openjdk/build/bsd-i586/hotspot/outputdir \n 
  HOTSPOT_EXPORT_PATH = 
/Users/headius/projects/openjdk/build/bsd-i586/hotspot/import \n \n

\nBootstrap Settings:\n  BOOTDIR = /usr/local/soylatte-amd64-1.0.3\n 
ALT_BOOTDIR = /usr/local/soylatte-amd64-1.0.3\n  BOOT_VER = /bin/sh: 
/usr/local/soylatte-amd641.0 [requires at least 1.5]\n  OUTPUTDIR = 
/Users/headius/projects/openjdk/build/bsd-i586\n    ALT_OUTPUTDIR = 
/Users/headius/projects/openjdk/build/bsd-i586\n  ABS_OUTPUTDIR = 
/Users/headius/projects/openjdk/build/bsd-i586\n \nBuild Tool 
Settings:\n  SLASH_JAVA = /NOT-SET\n    ALT_SLASH_JAVA = \n  VARIANT = 
OPT\n  JDK_DEVTOOLS_DIR = /NOT-SET/devtools\n    ALT_JDK_DEVTOOLS_DIR = 
\n  ANT_HOME = /usr/share/ant\n  UNIXCOMMAND_PATH = /bin/\n 
ALT_UNIXCOMMAND_PATH = \n  COMPILER_PATH = /usr/bin/\n 
ALT_COMPILER_PATH = \n  DEVTOOLS_PATH = /opt/local/bin/\n 
ALT_DEVTOOLS_PATH = \n  COMPILER_NAME = GCC\n  COMPILER_VERSION = \n 
CC_VER = 4.0 [requires at least 3.2]\n  ZIP_VER = 2.32 [requires at 
least 2.2]\n  UNZIP_VER = 5.52 [requires at least 5.12]\n  ANT_VER = 1.7 
[requires at least 1.6.3]\n  TEMPDIR = 
/Users/headius/projects/openjdk/build/bsd-i586/tmp\n \nBuild 
Directives:\n  OPENJDK = true\n  USE_HOTSPOT_INTERPRETER_MODE = \n 
PEDANTIC = \n  DEV_ONLY = \n  NO_DOCS = true\n  NO_IMAGES = \n 
TOOLS_ONLY = \n  INSANE = \n  COMPILE_APPROACH = parallel\n 
PARALLEL_COMPILE_JOBS = 2\n    ALT_PARALLEL_COMPILE_JOBS = \n  FASTDEBUG 
= \n  COMPILER_WARNINGS_FATAL = false\n  COMPILER_WARNING_LEVEL = \n 
INCREMENTAL_BUILD = false\n  CC_HIGHEST_OPT = \n  CC_HIGHER_OPT = \n 
CC_LOWER_OPT = \n  CXXFLAGS =  -O2 -fPIC -DCC_NOEX -W -Wall  -Wno-unused 
-Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -mstackrealign 
\n  CFLAGS =  -O2   -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused 
-Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -mstackrealign 
\n  BOOT_JAVA_CMD = /usr/local/soylatte-amd64-1.0.3/bin/java  -client 
-Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m\n 
BOOT_JAVAC_CMD = /usr/local/soylatte-amd64-1.0.3/bin/javac 
-J-XX:ThreadStackSize=768 -J-client -J-Xmx896m -J-Xms128m 
-J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii\n 
BOOT_JAR_CMD = /usr/local/soylatte-amd64-1.0.3/bin/jar\n 
BOOT_JARSIGNER_CMD = /usr/local/soylatte-amd64-1.0.3/bin/jarsigner\n 
JAVAC_CMD = 
/NOT-SET/re/jdk/1.7.0/promoted/latest/binaries/bsd-i586/bin/javac 
-J-XX:ThreadStackSize=768 -J-client -J-Xmx896m -J-Xms128m 
-J-XX:PermSize=32m -J-XX:MaxPermSize=160m  -source 1.5 -target 5 
-encoding ascii 
-Xbootclasspath:/Users/headius/projects/openjdk/build/bsd-i586/classes 
\n  JAVAH_CMD = 
/NOT-SET/re/jdk/1.7.0/promoted/latest/binaries/bsd-i586/bin/javah 
-bootclasspath /Users/headius/projects/openjdk/build/bsd-i586/classes\n 
  JAVADOC_CMD = 
/NOT-SET/re/jdk/1.7.0/promoted/latest/binaries/bsd-i586/bin/javadoc 
-J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m 
-J-XX:MaxPermSize=160m\n \nBuild Platform Settings:\n  USER = headius\n 
  PLATFORM = bsd\n  ARCH = i586\n  LIBARCH = i386\n  ARCH_FAMILY = 
i586\n  ARCH_DATA_MODEL = 32\n  ARCHPROP = i386\n  OS_VERSION = 9.6.0 
[requires at least 8.0]\n  OS_NAME = darwin\n  TEMP_FREE_SPACE = 
390050144\n  FREE_SPACE = 390050144\n  MB_OF_MEMORY = 2048\n \nGNU Make 
Settings:\n  MAKE = make\n  MAKE_VER = 3.81 [requires at least 3.78]\n 
MAKECMDGOALS = sanity\n  MAKEFLAGS = \n  SHELL = /bin/sh\n \nTarget 
Build Versions:\n  JDK_VERSION = 1.7.0\n  MILESTONE = internal\n 
RELEASE = 1.7.0-internal\n  FULL_VERSION = 
1.7.0-internal-headius_2009_01_31_12_53-b00\n  BUILD_NUMBER = b00\n 
\nExternal File/Binary Locations:\n  USRJDKINSTANCES_PATH = /opt/local\n 
  BUILD_JDK_IMPORT_PATH = 
/NOT-SET/re/jdk/1.7.0/promoted/latest/binaries\n 
ALT_BUILD_JDK_IMPORT_PATH = \n  JDK_IMPORT_PATH = 
/NOT-SET/re/jdk/1.7.0/promoted/latest/binaries/bsd-i586\n 
ALT_JDK_IMPORT_PATH = \n  LANGTOOLS_DIST = \n    ALT_LANGTOOLS_DIST = 
/Users/headius/projects/openjdk/build/bsd-i586/langtools/dist\n 
CORBA_DIST = \n    ALT_CORBA_DIST = 
/Users/headius/projects/openjdk/build/bsd-i586/corba/dist\n  JAXP_DIST = 
\n    ALT_JAXP_DIST = 
/Users/headius/projects/openjdk/build/bsd-i586/jaxp/dist\n  JAXWS_DIST = 
\n    ALT_JAXWS_DIST = 
/Users/headius/projects/openjdk/build/bsd-i586/jaxws/dist\n 
HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR\n 
ALT_HOTSPOT_DOCS_IMPORT_PATH = \n  HOTSPOT_IMPORT_PATH = 
/Users/headius/projects/openjdk/build/bsd-i586/hotspot/import\n 
ALT_HOTSPOT_IMPORT_PATH = 
/Users/headius/projects/openjdk/build/bsd-i586/hotspot/import\n 
HOTSPOT_CLIENT_PATH = 
/Users/headius/projects/openjdk/build/bsd-i586/hotspot/import/jre/lib/i386/client\n 
    ALT_HOTSPOT_CLIENT_PATH = \n  HOTSPOT_SERVER_PATH = 
/Users/headius/projects/openjdk/build/bsd-i586/hotspot/import/jre/lib/i386/server\n 
    ALT_HOTSPOT_SERVER_PATH = \n  CACERTS_FILE = 
./../src/share/lib/security/cacerts\n    ALT_CACERTS_FILE = \n 
CUPS_HEADERS_PATH = /usr/include\n    ALT_CUPS_HEADERS_PATH = 
/usr/include\n \nOpenJDK-specific settings:\n  FREETYPE_HEADERS_PATH = 
/usr/X11R6/include\n    ALT_FREETYPE_HEADERS_PATH = /usr/X11R6/include\n 
  FREETYPE_LIB_PATH = /usr/X11R6/lib\n    ALT_FREETYPE_LIB_PATH = 
/usr/X11R6/lib\n  X11_PATH = /usr/X11R6\n    ALT_X11_PATH = \n \nOPENJDK 
Import Binary Plug Settings:\n  BINARY_PLUGS_JARFILE = 
/Users/headius/jdk-7-icedtea-plugs/jre/lib/rt-closed.jar\n 
ALT_BINARY_PLUGS_JARFILE = \n  BINARY_PLUGS_PATH = 
/Users/headius/jdk-7-icedtea-plugs\n    ALT_BINARY_PLUGS_PATH = 
/Users/headius/jdk-7-icedtea-plugs\n  BUILD_BINARY_PLUGS_PATH = 
/NOT-SET/re/jdk/1.7.0/promoted/latest/openjdk/binaryplugs\n 
ALT_BUILD_BINARY_PLUGS_PATH = \n  PLUG_LIBRARY_NAMES = \n \nPrevious JDK 
Settings:\n  PREVIOUS_RELEASE_PATH = \n    ALT_PREVIOUS_RELEASE_PATH = 
\n  PREVIOUS_JDK_VERSION = 1.6.0\n    ALT_PREVIOUS_JDK_VERSION = \n 
PREVIOUS_JDK_FILE = \n    ALT_PREVIOUS_JDK_FILE = \n  PREVIOUS_JRE_FILE 
= \n    ALT_PREVIOUS_JRE_FILE = \n  PREVIOUS_RELEASE_IMAGE = \n 
ALT_PREVIOUS_RELEASE_IMAGE = \n

Sanity check passed.
Control bsd i586 1.7.0-internal all_product_build build started:
Control bsd i586 1.7.0-internal build_product_image build started:
make \
	        SKIP_FASTDEBUG_BUILD=true \
	        SKIP_DEBUG_BUILD=true \
	         \
	        generic_build_repo_series
/bin/mkdir -p ./build/bsd-i586
/bin/mkdir -p ./build/bsd-i586/j2sdk-image
/bin/mkdir -p /Users/headius/projects/openjdk/build/bsd-i586/langtools
(cd  ./langtools/make && \
	 make JDK_TOPDIR=/Users/headius/projects/openjdk/jdk 
JDK_MAKE_SHARED_DIR=/Users/headius/projects/openjdk/jdk/make/common/shared 
EXTERNALSANITYCONTROL=true TARGET_CLASS_VERSION=5 MILESTONE=internal 
BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 
FULL_VERSION=1.7.0-internal-headius_2009_01_31_12_53-b00 
PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 
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=32 COOKED_BUILD_NUMBER=0 
ANT_HOME="/usr/share/ant" 
ALT_OUTPUTDIR=/Users/headius/projects/openjdk/build/bsd-i586/langtools 
ALT_BOOTDIR=/usr/local/soylatte-amd64-1.0.3 all)
JAVA_HOME=/usr/local/soylatte-amd64-1.0.3 
ANT_OPTS=-Djava.io.tmpdir='/Users/headius/projects/openjdk/build/bsd-i586/langtools/build/ant-tmp' 
/usr/share/ant/bin/ant -diagnostics > 
/Users/headius/projects/openjdk/build/bsd-i586/langtools/build/ant-diagnostics.log
make[2]: *** [build] Error 1
make[1]: *** [langtools-build] Error 2
make: *** [build_product_image] Error 2



From charles.nutter at sun.com  Sat Jan 31 11:16:37 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Sat, 31 Jan 2009 13:16:37 -0600
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <4984A0F9.9060408@sun.com>
References: <49836365.6070206@sun.com> <498374E1.5030709@Sun.COM>
	<4984A0F9.9060408@sun.com>
Message-ID: <4984A395.20603@sun.com>

Charles Oliver Nutter wrote:
> Xiaobin Lu wrote:
>> Hi Charlie,
>>
>> The following page is perhaps all  you need.
>>
>> http://landonf.bikemonkey.org/code/java/SoyLatte_Meets_OpenJDK.20080819.html 
> 
> So far I'm not even getting into the build process following Landon's 
> instructions:

Ok, disregard...in the act of sending the email I saw it was logging ant 
results to a separate file, and in that file I found that my soylatte 
path was wrong.

So it started to build, but now I get this...should I not be using 
64-bit soylatte? I'm trying 32-bit now.

Done with parallel compiles: 
/Users/headius/projects/openjdk/corba/make/sun/corba/core
STATS: LIBRARY=ioser12, PRODUCT=sun, _OPT=-O2
Rebuilding 
/Users/headius/projects/openjdk/build/bsd-i586/corba/lib/i386/libioser12.so 
because of 
/Users/headius/projects/openjdk/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/obj/.files_compiled 
mapfile-vers
/usr/bin/gcc  -O2    -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused 
-Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -mstackrealign 
   -Di586 -DARCH='"i586"' -D_ALLBSD_SOURCE -DRELEASE='"1.7.0-internal"' 
-D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -I. 
-I/Users/headius/projects/openjdk/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/CClassHeaders 
-I../../../../src/solaris/javavm/export 
-I../../../../src/share/javavm/export 
-I../../../../src/share/javavm/include 
-I../../../../src/solaris/javavm/include -ICClassHeaders 
-I/usr/local/soylatte16-amd64-1.0.3/include 
-I/usr/local/soylatte16-amd64-1.0.3/include/darwin 
-I../../../../src/share/native/common 
-I../../../../src/solaris/native/common 
-I../../../../src/share/native/com/sun/corba/se/internal/io 
-I../../../../src/solaris/native/com/sun/corba/se/internal/io 
-L/Users/headius/projects/openjdk/build/bsd-i586/corba/lib/i386 
-dynamiclib -o 
/Users/headius/projects/openjdk/build/bsd-i586/corba/lib/i386/libioser12.so 
 
/Users/headius/projects/openjdk/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/obj/ioser.o 
   -L/usr/local/soylatte16-amd64-1.0.3/jre/lib/i386/server -ljvm 
-L/usr/local/soylatte16-amd64-1.0.3/jre/lib/i386 -ljava 
-L/usr/local/soylatte16-amd64-1.0.3/jre/lib/i386/server -ljvm
ld: library not found for -ljvm
collect2: ld returned 1 exit status
make[5]: *** 
[/Users/headius/projects/openjdk/build/bsd-i586/corba/lib/i386/libioser12.so] 
Error 1
make[4]: *** [build] Error 1
make[3]: *** [build] Error 1
make[2]: *** [build] Error 1
make[1]: *** [corba-build] Error 2
make: *** [build_product_image] Error 2



From charles.nutter at sun.com  Sat Jan 31 11:17:45 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Sat, 31 Jan 2009 13:17:45 -0600
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <4984A395.20603@sun.com>
References: <49836365.6070206@sun.com> <498374E1.5030709@Sun.COM>
	<4984A0F9.9060408@sun.com> <4984A395.20603@sun.com>
Message-ID: <4984A3D9.30809@sun.com>

Charles Oliver Nutter wrote:
> Charles Oliver Nutter wrote:
>> Xiaobin Lu wrote:
>>> Hi Charlie,
>>>
>>> The following page is perhaps all  you need.
>>>
>>> http://landonf.bikemonkey.org/code/java/SoyLatte_Meets_OpenJDK.20080819.html 
>> So far I'm not even getting into the build process following Landon's 
>> instructions:
> 
> Ok, disregard...in the act of sending the email I saw it was logging ant 
> results to a separate file, and in that file I found that my soylatte 
> path was wrong.
> 
> So it started to build, but now I get this...should I not be using 
> 64-bit soylatte? I'm trying 32-bit now.

32-bit seems to be going better...


From brian at experts-exchange.com  Fri Jan 30 13:09:01 2009
From: brian at experts-exchange.com (Brian Gardner)
Date: Fri, 30 Jan 2009 13:09:01 -0800
Subject: openjdk6 patch and install
Message-ID: <49836C6D.40707@experts-exchange.com>

Hello fellow BSD lovers,
I've created a patch process for patching openjdk6 for BSD (FreeBSD 
specifically), although I tried to keep all BSD versions in mind when 
creating my patch. 

http://beta.experts-exchange.com/articles/OS/Unix/BSD/Patch-for-OpenJDK6-on-BSD.html#top

Welcome to OpenJDK6 on BSD

First let me start with a little background on why I chose to port 
openjdk6, and then I'll discuss the process I took to do it.  I work for 
Experts Exchange recently we decided to move from Linux to FreeBSD.  
This decision came after a comprehensive test involving Linux, FreeBSD, 
and Solaris 10.  FreeBSD blew the others away doubling the performance 
of Linux and outperforming Solaris 10 by a significant margin as well.  
We have come across several issues with the port java/jdk16, including 
lack of jmap functionality to track down memory errors and instability 
running the CMS garbage collector with a heap over 2G.  I created the a 
patch to bring jmap functionality to java/jdk16.  My next task was to 
begin hardening the VM, however it hardly makes sense to work on 
java/jdk16, because it's missing lots of bugs fixes from sun.  openjdk7 
looked like the next choice to try and I compiled it up and gave it a 
try, however a third party library/software I was using didn't work and 
upon talking with terracotta developers they had no plans to support 
openjdk7 in the future.  I researched what exactly openjdk6 was and 
decided to give it a try.


How did I perform the Port

I started by duplicating jdk6 to bsd-port6.  Then I take the difference 
between jdk7 and bsd-port and import them.  I had trouble using patch 
-Nu jdk7 bsd-port because there were new files that contained long lines 
that patch complained about.  I whipped up a quick perl script to 
compare the directories and create the 
jdk7_bsd_changes_20090126.newfiles and jdk7_bsd_changes_20090126.patches 
directories.  Any file the was brand new to bsd-port was copied into 
jdk7_bsd_changes_20090126.newfiles to avoid the patch issue with long 
lines.  jdk7_bsd_changes_20090126.patches contains a separate patch for 
each file the was changed between jdk7 and bsd-port.  Not all of these 
patches applied cleanly so I then went through about 40 .rej files and 
applied the patches by hand, keeping track of the changes.  When 
compiling I released the build structure had changed between jdk6 and 
jdk7 and bsd-port6/hotspot/make/bsd/ had to be moved to 
bsd-port6/hotspot/build/bsd.  Makefiles also had to be patched to 
complete the change.  custom-patches contains these patches.


Applying the patch.
*) run import_patch.pl
   - download jdk6 using mercurial to _jdk6
   - dupicate _jdk6 to bsd-port6
   - apply jdk7-bsd-changes-20090126
   - apply custom-patches
*) now compile, I've included a build_bsd-port6.sh script that I use to 
start compiling



Notes of Custom Patches

COPIED FROM bsd-port to bsd-port6
jdk/src/solaris/native/java/io/UnixFileSystem_md.c
jdk/src/solaris/classes/java/lang/UNIXProcess.java.bsd


HAND PATCHED
jdk/src/solaris/bin/java_md.c
jdk/src/share/classes/sun/tools/jar/Main.java
jdk/make/sun/awt/Makefile
jdk/make/tools/freetypecheck/Makefile
jdk/src/share/bin/java.c
jdk/src/share/native/common/check_code.c
jdk/src/share/transport/socket/socketTransport.c
jdk/src/solaris/native/java/lang/UNIXProcess_md.c
jdk/src/solaris/native/sun/nio/ch/Net.c
hotspot/src/share/vm/runtime/os.cpp
hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp
hotspot/src/share/vm/utilities/macros.hpp
hotspot/src/share/vm/utilities/vmError.cpp
hotspot/src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep
hotspot/src/share/vm/gc_implementation/includeDB_gc_parNew
jdk/make/common/internal/BinaryPlugs.gmk
jdk/make/common/shared/Platform.gmk
hotspot/src/cpu/x86/vm/stubGenerator_x86_64.cpp
hotspot/src/cpu/x86/vm/x86_32.ad
hotspot/src/cpu/x86/vm/interpreterRT_x86_32.cpp
hotspot/src/cpu/x86/vm/runtime_x86_32.cpp
jdk/src/share/classes/java/lang/ProcessBuilder.java

MAKEFILES
mv bsd-port6/hotspot/make/bsd bsd-port6/hotspot/build/bsd

NOTES
jdk/src/share/bin/java.c - was hand patched, however I wasn't able to 
test compiling on Mac OS X, and I worry it won't compile

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_openjdk6_freebsd_0.1.0.tbz
Type: application/octet-stream
Size: 410584 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20090130/d3db3c96/patch_openjdk6_freebsd_0.1.0.tbz 

From charles.nutter at sun.com  Sat Jan 31 14:55:25 2009
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Sat, 31 Jan 2009 16:55:25 -0600
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <4984A3D9.30809@sun.com>
References: <49836365.6070206@sun.com> <498374E1.5030709@Sun.COM>
	<4984A0F9.9060408@sun.com> <4984A395.20603@sun.com>
	<4984A3D9.30809@sun.com>
Message-ID: <4984D6DD.3000809@sun.com>

Charles Oliver Nutter wrote:
> Charles Oliver Nutter wrote:
>> Charles Oliver Nutter wrote:
>>> Xiaobin Lu wrote:
>>>> Hi Charlie,
>>>>
>>>> The following page is perhaps all  you need.
>>>>
>>>> http://landonf.bikemonkey.org/code/java/SoyLatte_Meets_OpenJDK.20080819.html 
>>> So far I'm not even getting into the build process following Landon's 
>>> instructions:
>> Ok, disregard...in the act of sending the email I saw it was logging ant 
>> results to a separate file, and in that file I found that my soylatte 
>> path was wrong.
>>
>> So it started to build, but now I get this...should I not be using 
>> 64-bit soylatte? I'm trying 32-bit now.
> 
> 32-bit seems to be going better...

Looks like I'm up and going on 32-bit. Thanks for the help!


From kurt at intricatesoftware.com  Sat Jan 31 15:10:40 2009
From: kurt at intricatesoftware.com (Kurt Miller)
Date: Sat, 31 Jan 2009 18:10:40 -0500
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <38a53eb30901311031i2354b90eo4e37fc80b69f63db@mail.gmail.com>
References: <49836365.6070206@sun.com>	<38a53eb30901301415u232e8700p15b9faa2b94c5d0f@mail.gmail.com>	<49844ED9.4070007@intricatesoftware.com>
	<38a53eb30901311031i2354b90eo4e37fc80b69f63db@mail.gmail.com>
Message-ID: <4984DA70.9040308@intricatesoftware.com>

Hi Ben,

Ben Evans wrote:
> On Sat, Jan 31, 2009 at 1:15 PM, Kurt Miller <kurt at intricatesoftware.com
> <mailto:kurt at intricatesoftware.com>> wrote:
> 
>     Ben Evans wrote:
>     > Hi Charlie,
>     >
>     > My understanding is that the current bsd-port is still broken for OS X
>     > and that we expect it to be unbroken sometime soon.
> 
>     To unbreak the OS X build you can issue the following commands which
>     will revert the minor breakage in the tree right now. But first enable
>     the mq extension in ~/.hgrc to enable the hg strip command:
> 
>     [extensions]
>     hgext.mq <http://hgext.mq> =
> 
>     $ cd bsd-port
>     $ cd hotspot
>     $ hg strip 32826d5f1894
>     $ cd ../jdk
>     $ hg strip 97139295a172
> 
>     Temporally DEVTOOLS_PATH needs to be set to point an existing directory.
>     It doesn't matter what dir since OS X doesn't use it, just something to
>     satisfy the sanity check.
> 
> 
> OK.
> 
> I'm having trouble with the ALT_JDK_IMPORT_PATH sanity check. My make
> line seems basically identical to yours - except that you don't set
> ALT_JDK_IMPORT_PATH.
> 
> If I try building without that set, I get tons of warnings and then fail
> immediately with this:
> 
> # Running javac:
> Check_ALT_JDK_IMPORT_PATH/bin/javac -J-XX:ThreadStackSize=768 -J-client
> -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -source
> 1.5 -target 5 -encoding ascii -classpath
> /usr/local/soylatte16-i386-1.0.3/lib/tools.jar -sourcepath
> /Users/boxcat/projects/jdk7-2009-01-30/sources/build/bsd-i586/corba/gensrc:../../../src/solaris/classes:../../../src/share/classes
> -d
> /Users/boxcat/projects/jdk7-2009-01-30/sources/build/bsd-i586/corba/classes
> @/Users/boxcat/projects/jdk7-2009-01-30/sources/build/bsd-i586/corba/tmp/sun/javax.transaction.xa/.classes.list
> /bin/sh: Check_ALT_JDK_IMPORT_PATH/bin/javac: No such file or directory
> make[4]: *** [.compile.classlist] Error 127
> 
> Could you post the output of set in your build shell so I can try and
> spot any differences in the way our environments are setup?

I'm sorry I only have OS X on my PowerPC PowerBook. Currently I don't
have an OS X system capable of doing a build. :(

You can safely ignore the warning about ALT_JDK_IMPORT_PATH not being
set.

Perhaps try starting the build like this to ensure your environment
is clean:

env -i PATH=${PATH} make \
ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 \
ALT_BINARY_PLUGS_PATH=/usr/local/lib/jdk-7-icedtea-plugs \
ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \
ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \
ANT_HOME=/usr/share/ant \
NO_DOCS=true \
HOTSPOT_BUILD_JOBS=1 \
DEVTOOLS_PATH=/usr/bin

Regards,
-Kurt


From stephen.bannasch at deanbrook.org  Sat Jan 31 18:43:24 2009
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Sat, 31 Jan 2009 21:43:24 -0500
Subject: Step-by-step OpenJDK on OS X?
In-Reply-To: <49836365.6070206@sun.com>
References: <49836365.6070206@sun.com>
Message-ID: <p06240800c5aab2d8e594@[192.168.1.114]>

At 2:30 PM -0600 1/30/09, Charles Oliver Nutter wrote:
>I've read through some of the backthreads and there's a lot of noise
>about getting OpenJDK to build, having this issue, applying that patch.
>I'm wondering what the bottom line is today:
>
>- Is it possible to build OpenJDK on OS X right now? Which
>versions/branches/etc?
>- Has anyone aggregated the instructions required to do so yet? I mostly
>got an older revision to build using Landon Fuller's walkthrough, but
>that's pretty dated now.

Building the BSD port of OpenJDK -- Java 1.7 on Max OS X 10.5.x

This is lightly adapted from Landon Fuller's instructions here:

   http://landonf.bikemonkey.org/2008/08/20#SoyLatte_Meets_OpenJDK.20080819

Dependencies:

I'm using Landon Fuller's 32-bit SoyLatte binaries to build the 
OpenJDK bsd port:

   http://landonf.bikemonkey.org/static/soylatte/
 
http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2

After downloading the binaries I copied then to:

   /usr/local/soylatte16-i386-1.0.3

Get Mercurial:

   sudo port install mercurial +bash_completion

and add the Forest extension:

   hg clone http://hg.akoha.org/hgforest

I'm actually using Patrick M?zard's clone of hgforest (just a couple 
of fixes to Simons work):

   hg clone http://bitbucket.org/pmezard/hgforest-crew

And after that add an 'hgext.forest' item with the path to forest.py 
in the extensions section in your ~/.hgrc file.

Here's mine:

   $ cat ~/.hgrc
   [ui]
   username = Stephen Bannasch <stephen.bannasch at gmail.com>
   [extensions]
   hgext.forest=/Users/stephen/dev/mercurial/hgforest-crew/forest.py

You'll also need Kurt Miller's binary plugs for the BSD port:

   http://landonf.bikemonkey.org/static/soylatte/jdk-7-icedtea-plugs-1.6.tar.gz

I unpacked them here:

   ~/dev/java/jdk-7-icedtea-plugs

Checkout all the code using hg/forest:

   hg fclone http://hg.openjdk.java.net/bsd-port/bsd-port

Here's what my bsd-port dir looks like:

   $ cd bsd-port/

   $ ls -l
   total 528
   -rw-r--r--   1 stephen  staff    1503 Dec 15 12:29 ASSEMBLY_EXCEPTION
   -rw-r--r--   1 stephen  staff   19241 Dec 15 12:29 LICENSE
   -rw-r--r--   1 stephen  staff   16336 Dec 15 12:29 Makefile
   -rw-r--r--   1 stephen  staff    1207 Dec 15 12:29 README
   -rw-r--r--   1 stephen  staff   87215 Jan 25 23:04 README-builds.html
   -rw-r--r--   1 stephen  staff  127532 Dec 15 12:29 THIRD_PARTY_README
   drwxr-xr-x   4 stephen  staff     136 Jan 26 00:51 build
   -rwxr--r--@  1 stephen  staff     373 Jan 26 03:00 build.sh
   drwxr-xr-x  11 stephen  staff     374 Jan 25 23:06 corba
   drwxr-xr-x  13 stephen  staff     442 Jan 25 23:06 hotspot
   drwxr-xr-x  11 stephen  staff     374 Jan 25 23:06 jaxp
   drwxr-xr-x  11 stephen  staff     374 Jan 25 23:06 jaxws
   drwxr-xr-x  12 stephen  staff     408 Jan 25 23:07 jdk
   drwxr-xr-x  12 stephen  staff     408 Jan 25 23:07 langtools
   drwxr-xr-x  18 stephen  staff     612 Dec 15 12:29 make

I added the script build.sh:

   $ cat build.sh
   # source build.sh
   LC_ALL=C
   LANG=C
   unset CLASSPATH
   unset JAVA_HOME
   make \
   ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3/ \
   ALT_BINARY_PLUGS_PATH=/Users/stephen/dev/java/jdk-7-icedtea-plugs \
   ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include \
   ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib \
   ALT_CUPS_HEADERS_PATH=/usr/include \
   ANT_HOME=/usr/share/ant \
   NO_DOCS=true \
   HOTSPOT_BUILD_JOBS=1

I build openjdk like this:

   source build.sh

This takes about 10m on my 2.5 GHz Intel Core 2 Duo MacBook Pro.

If it works I then copy it to /usr/local adding a suffix of my 
username and the date:

   sudo mv build/bsd-i586/j2sdk-image 
/usr/local/java-1.7.0-internal-`date "+%Y_%m_%d"``

   $ /usr/local/java-1.7.0/bin/java -version
   openjdk version "1.7.0-internal"
   OpenJDK Runtime Environment (build 
1.7.0-internal-stephen_2009_01_25_23_54-b00)
   OpenJDK Server VM (build 14.0-b10, mixed mode)

Then I link /usr/local/java-1.7.0 to the latest build:

   $ cd /usr/local
   $ sudo ln -s java-1.7.0-internal-`date "+%Y_%m_%d"` java-1.7.0

THese functions are in update-usr-local.sh:

 
#!/bin/sh                                                                                                                                                                                                           
   buildname=java-1.7.0-internal-`date "+%Y_%m_%d"`
   cp -r build/bsd-i586/j2sdk-image /usr/local/$buildname
   cd /usr/local
   sudo rm -f java-1.7.0
   sudo ln -s $buildname java-1.7.0

This results in:

   $ ls -l /usr/local
   ...
   lrwxr-xr-x    1 root  wheel    38 Jan 31 20:58 java-1.7.0 -> 
java-1.7.0-internal-2009_01_31
   drwxr-xr-x   15 root  wheel   510 Jan 31 21:37 java-1.7.0-internal-2009_01_31

Updating:

   $ cd bsd-port
   $ hg fpull -u
   $ source build.sh
   $ sudo ./update-usr-local.sh

I've modified the function pickjdk in my ~./bash_profile like this to 
add java 1.7.0

#
# pickjdk: for switching between Java versions:
# From Nick Sieger: http://pastie.org/170326
#   "I just symlink soylatte to:
# 
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0-soylatte/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0-soylatte"
#
_macosx()
{
     if [ $(uname -s) = Darwin ]; then
         return 0
     else
         return 1
     fi
}

JDKS_ROOT=
if [ $(uname -s) = Darwin ]; then
     JDKS_ROOT=/System/Library/Frameworks/JavaVM.framework/Versions
fi

SOYLATTE_HOME=${HOME}/dev/java/src/soylatte/control/build/bsd-amd64
SOYLATTE_32_HOME=/usr/local/soylatte16-i386-1.0.3
JAVA_1_7_0_HOME=/usr/local/java-1.7.0

pickjdk()
{
     if [ -z "$JDKS_ROOT" ]; then
         return 1
     fi

     declare -a JDKS
     local n=1 jdk total_jdks choice=0 currjdk=$JAVA_HOME explicit_jdk
     for jdk in $JDKS_ROOT/[0-9]*; do
         if [ -d $jdk -a ! -L $jdk ]; then
             echo -n " $n) $(basename $jdk)"
             if _macosx; then
                 jdk=$jdk/Home
             fi
             if [ $jdk = "$currjdk" ]; then
                 echo " < CURRENT"
             else
                 echo
             fi
             JDKS[$n]=$jdk
             total_jdks=$n
             n=$[ $n + 1 ]
         fi
     done
     echo " $n) Soylatte-amd64"
     JDKS[$n]=$SOYLATTE_HOME
     n=$[ $n + 1 ]
     echo " $n) Soylatte16-i386-1.0.3"
     JDKS[$n]=$SOYLATTE_32_HOME
     n=$[ $n + 1 ]
     echo " $n) 1.7.0"
     JDKS[$n]=$JAVA_1_7_0_HOME
     n=$[ $n + 1 ]
     echo " $n) None"
     JDKS[$n]=None
     total_jdks=$n

     if [ $total_jdks -gt 1 ]; then
         while [ -z "${JDKS[$choice]}" ]; do
             echo -n "Choose one of the above [1-$total_jdks]: "
             read choice
         done
         else
         choice=1
     fi

     if [ -z "$currjdk" ]; then
         currjdk=$(dirname $(dirname $(type -path java)))
     fi

     if [ ${JDKS[$choice]} != None ]; then
         export JAVA_HOME=${JDKS[$choice]}
     else
         unset JAVA_HOME
     fi

     explicit_jdk=
     for jdk in ${JDKS[*]}; do
         if [ "$currjdk" = "$jdk" ]; then
             explicit_jdk=$jdk
             break
         fi
     done

     if [ "$explicit_jdk" ]; then
         if [ -z "$JAVA_HOME" ]; then
             PATH=$(echo $PATH | sed "s|$explicit_jdk/bin:*||g")
         else
             PATH=$(echo $PATH | sed "s|$explicit_jdk|$JAVA_HOME|g")
         fi
     elif [ "$JAVA_HOME" ]; then
         PATH="$JAVA_HOME/bin:$PATH"
     fi

     hash -r
     unset JDKS
}