Sun's OpenJDK in Debian?

[Mark Wielaard]

(CC openjdk distro-pkg-dev to keep them in the loop about the progress)

On Sun, 2007-06-10 at 12:14 +0100, Andrew Haley wrote:
> Mark Wielaard writes:
> 
>  > Only bootstraps on Fedora 7 for now, but we are making (very) slow
>  > progress to get things to build fully on Debian also.
> 
> Ofergoodnessake, it's been three whole days!  :-)

Four already! But...
IcedTea is served: openjdk/control/build/linux-i586

$ /home/mjw/icedtea/openjdk/control/build/linux-i586/bin/javac HelloWorld.java 

$ /home/mjw/icedtea/openjdk/control/build/linux-i586/bin/java HelloWorld
Hello World!
Greetings Earth!

vm: OpenJDK Client VM
version: 1.7.0-internal-mjw_10_jun_2007_20_29-b00
vendor: Sun Microsystems Inc.

This is a bit faked though. It is on a Debian 3.0/Etch install, which
definitely doesn't have the latest gcj, so I build myself a gcc from svn
trunk. Michael and I found some small issues in his last
icedtea-builddeps that partially explain the problems found in:
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-June/000035.html
There is a serializer.jar which provides the xalan stuff and some parts
of the build seem to unconditionally use gawk. Both issues should be
solved by Michael's latest icedtea-builddeps package (available as apt
sources line at deb http://people.debian.org/~mkoch/java/ ./).

Also on this install ecj wasn't always picking up the bootstrap
classpath, so I had to fake that by adding the following to the javac
script in icedtea and by creating my own wrapper of ecj (and point
--with-ecj at it):

libgcjjar=/home/mjw/gcc/install/share/java/libgcj-4.3.0.jar

case "$*" in
  *-bootclasspath*) ;;
  *) bcoption="-bootclasspath $libgcjjar"
esac

CLASSPATH=/usr/share/java/ecj.jar${CLASSPATH:+:}$CLASSPATH \
  /home/mjw/gcc/install/bin/gij \
  org.eclipse.jdt.internal.compiler.batch.Main -1.5 -nowarn \
  $bcoption $NEW_ARGS

Finally since I was using a x86 xen guest on a x86_64 xen host the build
guessed the architecture wrong at one point which I just manually
corrected. And since this xen guest doesn't have proper tls support I
had to fake out libunpack.so and libwaiters.so which (indirectly) seem
to use that.

And I didn't yet try to make it bootstrap itself.

So lots of tricks to play. But theoretically it is possible :)

Cheers,

Mark