Building IcedTea7 Using BSD option On OS X

Fri Jan 2 22:26:05 PST 2009

Andrew,

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

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

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

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

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

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

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

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

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

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

>
> >>
> >> > Michael
> >> >
> >> > On Tue, Dec 30, 2008 at 2:31 AM, Andrew John Hughes
> >> > <gnu_andrew at member.fsf.org> wrote:
> >> >>
> >> >> 2008/12/30 Michael Franz <mvfranz at gmail.com>:
> >> >> > Hi,
> >> >> >
> >> >> > I tried to build IcedTea 7 using the --with-project=bsd option.
>  Most
> >> >> > of
> >> >> > my
> >> >> > issues are with applying the patches.  I have not gone through all
> of
> >> >> > them,
> >> >> > but they seem to fail around the bsd specific lines.
> >> >> >
> >> >> > What would be the best way to handle these differences?
> >> >> >
> >> >> > Michael
> >> >> >
> >> >>
> >> >> Let us know the specifics and we'll work out a solution.  As I say,
> we
> >> >> enabled the option but no-one on the IcedTea team uses BSD so it
> >> >> hasn't been tested.
> >> >> --
> >> >> Andrew :-)
> >> >>
> >> >> Support Free Java!
> >> >> Contribute to GNU Classpath and the OpenJDK
> >> >> http://www.gnu.org/software/classpath
> >> >> http://openjdk.java.net
> >> >>
> >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> >> >> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
> >> >
> >> >
> >>
> >>
> >> --
> >> Andrew :-)
> >
> > Michael
> >
> --
> Andrew :-)
>
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20090103/a63a3802/attachment.html 