IcedTea 7 Patches for with-project=bsd - A Plan

Andrew John Hughes gnu_andrew at member.fsf.org
Tue Mar 10 10:46:30 PDT 2009 

2009/3/10 Michael Franz <mvfranz at gmail.com>:
>
>
> On Mon, Mar 9, 2009 at 9:54 AM, Andrew John Hughes
> <gnu_andrew at member.fsf.org> wrote:
>>
>> 2009/3/9 Michael Franz <mvfranz at gmail.com>:
>> >
>> >
>> > On Mon, Mar 9, 2009 at 6:40 AM, Andrew John Hughes
>> > <gnu_andrew at member.fsf.org> wrote:
>> >>
>> >> 2009/3/9 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>> >> > 2009/3/9 Michael Franz <mvfranz at gmail.com>:
>> >> >> Here are the patches against IcedTea7 changeset:   1623:5bda1b46a64f
>> >> >> they
>> >> >> allow Fedora 10 to build the bsd-port  changeset:   65:72d04adc33f8.
>> >> >> The
>> >> >> build is not perfect and does not work as well as an older set of
>> >> >> patches
>> >> >> (the build fails with some genxx.sh script but finishes fine if
>> >> >> re-run).
>> >> >>
>> >> >> Since my original attempt the nio2 was added so, this needs to be
>> >> >> disabled.
>> >> >> I have tested configured as:
>> >> >> ./configure --without-rhino --disable-liveconnect --disable-xrender
>> >> >> --with-hotspot-build --disable-nio2 --with-project=bsd
>> >> >>
>> >> >
>> >> > b50 on includes NIO2 so disabling it is no longer an option.  The BSD
>> >> > tree should be synced to this.
>> >> >../../../src/solaris/native/sun/nio/ch/FileDispatcherImpl.c: In
>> >> > function 'Java_sun_nio_ch_FileDispatcherImpl_lock0':
>> ../../../src/solaris/native/sun/nio/ch/FileDispatcherImpl.c:195:
>> error: 'sun_nio_ch_FileDispatcherImpl_NO_LOCK' undeclared (first use
>> in this function)
>> ../../../src/solaris/native/sun/nio/ch/FileDispatcherImpl.c:195:
>> error: (Each undeclared identifier is reported only once
>> ../../../src/solaris/native/sun/nio/ch/FileDispatcherImpl.c:195:
>> error: for each function it appears in.)
>> ../../../src/solaris/native/sun/nio/ch/FileDispatcherImpl.c:197:
>> error: 'sun_nio_ch_FileDispatcherImpl_INTERRUPTED' undeclared (first
>> use in this function)
>
> Looks like the BSD port was bumped to b50 on March 5 (I was using March 1)
>
>>
>> >> >> This almost builds on OS X, but I have not figured out my issue with
>> >> >> jar and
>> >> >> how specify a new include directory and a new lib directory.  These
>> >> >> patches
>> >> >> do not allow zero to build.  I did have this working in the previous
>> >> >> version.
>> >> >>
>> >> >
>> >> > twisti added some support for additional lib directories IIRC, when
>> >> > adding OpenSolaris support.
>> >> > Check the bit where you added BSD support.
>> >> >

In acinclude.m4:

AC_DEFUN([SET_OS_DIRS],
[
  case "${host_os}" in
    *linux*)
      BUILD_OS_DIR=linux
      OS_PATH=
      ;;
    *solaris*)
      BUILD_OS_DIR=solaris
      OS_PATH=/opt/SunStudioExpress/bin:/opt/SUNWpro/bin:/usr/gnu/bin
      ;;
    *darwin*|*bsd*)
      BUILD_OS_DIR=bsd
      OS_PATH=
      ;;
    *)
      AC_MSG_ERROR([unsupported operating system ${host_os}])
      ;;
  esac
  AC_SUBST(BUILD_OS_DIR)
  AC_SUBST(OS_PATH)
])

OS_PATH can be used for binaries.  Something similar (a OS_LIBPATH) is
probably needed for libraries.

>> >> >> The ecj build requires gjavah as there are patches that assume
>> >> >> gjavah
>> >> >> is
>> >> >> used instead of a standard javah, it seems gjavah generates code a
>> >> >> little
>> >> >> differently.
>> >> >>

b50 has another issue in this area which I'm working on now.

>> >> >
>> >> > This is intentional.  The ecj bootstrap is designed for GNU
>> >> > Classpath-based solutions and was designed around gcj.  It probably
>> >> > should be split into individual tests for specific bits of missing
>> >> > functionality.
>> >> >
>> >> >> bsd-Makefile.am.patch should indicate how I worked the patches into
>> >> >> the
>> >> >> build system.
>> >> >>
>> >>
>> >> I'm not sure what this does.  It seems to introduce a whole heap of
>> >> duplicate patches which would be impossible to maintain.
>> >
>> > What I did is determine which IcedTea patches fail on the BSD port and
>> > moved
>> > the failing parts into two files.  The original failing part is in jdk7
>> > directory which are applied when using IcedTea's normal build. The same
>> > patches are then applied to the bsd port and put into bsd directory.
>> >
>> > The failing parts are mostly where there are new conditionals around BSD
>> > and
>> > caused the files to be different enough that patch could not figure out
>> > how
>> > to apply them.  If the FUZZ level is increased from 0 to 3 more of he
>> > patches apply without modification.
>> >
>>
>> We don't really want to be maintaining about a dozen patches just for
>> BSD, so we need to look at why the BSD versions differ and whether the
>> changes could be pushed to the main tree instead.
>
> It would be nice to have a minimal set of patches to for BSD.  Like I said,
> most of the patches deal with BSD conditional logic that is not in the main
> tree.

Each patch really needs to be treated on a case-by-case basis i.e.
finding out why they failed, why the files in BSD are different,
whether the BSD changes are generally useful/could go upstream, etc.

>>
>> >>
>> >> Note that we want most IcedTea patches to go upstream where possible,
>> >> and some of those in your version of IcedTea have already.
>> >
>> > I am not sure what you mean by this.
>>
>> We don't want to be maintaining the 100+ patches in IcedTea forever :)
>> Some have already gone upstream to OpenJDK, some since your patch.
>> We also now have an IcedTea project within the OpenJDK space that can
>> be used for patches submitted under the SCA,
>> so hopefully most of the patches in IcedTea will start to disappear.
>>
>> It would be good to also get any relevant patches into the BSD tree
>> too.  As you'll have experienced, things change rapidly enough that
>> maintaining all these patches is a major pain!
>
> Especially with limited time to spend on it.
>>
>> The version I started with is not that
>> > old maybe 2 weeks.
>>
>> 2 weeks is a long time with 7 -- the existence of
>> icedtea-no-bcopy.patch suggests it's at least prior to b47, while
>> IcedTea7 now supports b49 and I'm working on b50.
>>
>> The BSD port is constantly merging in changes from up
>> > stream.  Were there many patches in those two weeks?
>>
>> There were changes to upstream OpenJDK7:
>>
>> http://download.java.net/jdk7/changes/jdk7-b47.html
>> http://download.java.net/jdk7/changes/jdk7-b48.html
>> http://download.java.net/jdk7/changes/jdk7-b49.html
>>
>> and I merged in the latest patches from IcedTea6 (which is about
>> another 60 changesets but this was mostly plugin/Shark updates).
>>
>> >  Is this more of a
>> > timing issue?
>>
>> It would be good to have a heads-up if you're working on something, as
>> I don't want your work to be wasted.
>> It would probably be better to send patches to the list as you go
>> along.  We can probably sort out commit access to IcedTea7 pretty
>> easily, but patches need to be approved first anyway.
>
> I was not expecting all of my work to go in, I did expect some of it to be
> wasted.  Finding a better way to waste less of it would be appreciated.  If
> most of IcedTea is going to end up into the main tree, then maybe we can get
> the changes into the BSD tree first.

But we don't really want any work to be wasted, and I don't think it
is.  At the very least, you've found which patches are problematic.
The reason I don't want to accept things as is is simply because
adding adjusted patches is more of a short term fix than a long-term
solution.

Not only is it hoped that most of the IcedTea patches will go
upstream, but IcedTea should shortly have its own forest, like the BSD
port.  The BSD folks are more than welcome to apply the patches to
their forest too.
Of course, you could then use Mercurial to create a local hybrid of
the BSD and IcedTea trees.

>
>>
>> > Or is this a difference between IcedTea 6 and 7?
>> >
>>
>> Well they support a completely different OpenJDK tree :D
>> So yes, that makes quite a difference and now changes to the upstream
>> 7 tree seem to be happening much more rapidly, it's harder to keep up.
>>  Hence why I want to get as much as possible upstream and maintain
>> most of it in our own forest - a lot of the patches then become
>> one-time Mercurial merges.
>>
>> I didn't realise you were building on a GNU/Linux box (or rather, that
>> the BSD port would build there). I could probably also test that.
>
> Well, since IcedTea is building the JDK7 repo and staying up-to-date, there
> is no reason it should not build on linux (assuming JDK7 builds on linux).
> Most of the patches (I think) are to deal with the bootstrap via gcj/ecj.
>

Yes, the 7 repo, not the BSD one.  But I suppose there isn't much
difference on a non-BSD box.
The patches for bootstrapping are just those in patches/ecj/*.  There
is a large number of other patches
that do all sorts of build and bug fixes.

Note that there are --with-openjdk/--with-icedtea options to build
without the bootstrap stage. There are probably issues with using
these with a proprietary JDK too (I'm thinking of Apple's JDK here,
which you mentioned previously); that's because no-one works on such
support.

>>
>> I've been meaning to set up a virtual image of FreeBSD to test, but
>> not got round to it.  I also have OSX, but that means I actually have
>> to use it... :( But having IcedTea supporting PPC OSX would be kinda
>> nice.
>
> Do you have a PowerPC or an Intel based Mac?
>

I have both, but both primarily run GNU/Linux.

> I run linux in multiple VMs to help with testing.  If I cannot build the BSD
> repo under linux, I don't have much hope figuring out how IcedTea builds.
>

IcedTea *should* be easier than raw OpenJDK :)

>>
>> >>
>> >> >> Michael
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> > --
>> >> > Andrew :-)
>> >> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Andrew :-)
>>
>
>



-- 
Andrew :-)

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

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

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

More information about the distro-pkg-dev mailing list