Cross-compiling IcedTea7

[Thierry Reding]

* Xerxes Ranby wrote:
> Thierry Reding wrote:
> >Hi,
> >
> >I've been trying to get IcedTea 7 to cross-compile, without much success. So
> >I went and gave OpenJDK a try and had some more luck. My plan now is to try
> >and take some of the insight from that and give IcedTea another try.
> How far did you get by cross compiling OpenJDK directly? Do you mind
> elaborate what worked and what did not.
> 
> What are your host and target for your cross compilation?

My target platform is an i686 processor, while my build computer is x86_64.
Getting this to work was not very difficult because build-time tests were
actually able to execute. But I also managed to get things to build for an
ARM target.

I've been able to runtime test the cross-build, using the cross-built javac on
the target to build a simple "Hello, World" application and run it with the
cross-built java interpreter. However I only tested the runtime on the i686
target because I couldn't get my hands on ARM hardware.

> >One of the problems with IcedTea is that it runs two iterations of the build,
> If you already have a bootstrap JVM then you can make Icedtea 7 skip
> the bootstrap generation by configure it with
> --disable-bootstrap and thus only need to run one iteration.

Yeah, I was thinking about that as well. But then I thought it would be just
as nice if IcedTea was able to bootstrap everything itself, even in
cross-compilation mode, instead of me building OpenJDK once and then run the
IcedTea build with --disable-bootstrap.

> >the bootstrap stage as well as the final stage. Am I correct in assuming that
> >when cross-compiling the bootstrap stage should actually be built for the
> >architecture of the build host, and the final stage should then use that
> >bootstrap to build OpenJDK for the target architecture (or host architecture
> >in autoconf speak)?
> Yes you are correct, the bootstrap JVM needs to be run by the build host.
> 
> You also must make sure that some helper binaries like sizer are
> generated for the build host during the final build stage. Sanity
> checks that runs binaries of the final build like the hotspot
> "test_gamma queens" must also be disabled in a cross-compile setup.

Right, that's the sort of errors I was running into when building on the
x86_64 build computer for the ARM target. I worked around that by defining
HOSTCC, HOSTCPPFLAGS, HOSTCFLAGS and HOSTLDFLAGS.

> >Currently both stages are built for one architecture,
> >which obviously will not work for a cross-compile.
> In late 2008 Robert Schuster sorted out how to cross-compile Icedtea
> 6 and how to automated the process using the Jalimo and OpenEmbedded
> cross-compile build environment.
> http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/
> - summary of steps involved to cross-compile icedtea6 and what needs
> to be looked into to make OpenJDK cross-compile aware.
> http://wiki.evolvis.org/jalimo/index.php/CrossCompilingOpenJDK -
> Roberts detailed notes on the steps needed for manual
> patching/hacking of OpenJDK to make it work.
> 
> The Jalimo cross-compile recipes have since evolved and we can up to
> date automate  cross-compiles up to icedtea 6 1.7.x.
> 
> You might get some inspiration from the Jalimo recipes on how to
> make Icedtea 7 and OpenJDK in general more cross-compile-able.
> https://evolvis.org/scm/viewvc.php/trunk/oe-overlay/packages/icedtea/?root=jalimo

Perhaps I should have mentioned that. Initially I tried getting the
cross-compile to work based on the Jalimo recipes, though without success.
But a the inspiration from Robert's work helped a lot when cross-building
OpenJDK.

One particular problem comes to mind: IcedTea (and by default OpenJDK as
well) don't seem to build everything in the correct order. Corba is usually
built before Hotspot, which fails at the linking stage of corba because the
libjvm.so is missing. The same goes for libjava.so (built by OpenJDK's jdk
target). This is not a problem for native builds because libjvm.so and
libjava.so are either provided by gcj in the bootstrap phase or later by the
libraries from the bootstrap build in the final phase. This obviously fails
for the final phase in a cross-compile.

> >One general question is how much of the changes that actually modify code in
> >OpenJDK can go upstream and what needs to go into IcedTea patches.
> If you have signed the SCA then please make as much as possible go
> upstream into OpenJDK!

I should probably do that then. Unfortunately I'm on a pretty tight schedule
(who isn't?), so I'm hoping I can get as much as possible upstream (either
OpenJDK or IcedTea).

> The IcedTea project have the ability to locally host contributions
> and patches that for some reason cant go upstream into OpenJDK.
> >Preparing
> >patches against an OpenJDK tree and applying them in the IcedTea build also
> >turns out not to be an optimal workflow. What is the usual practice?
> There are no usual practise ;)
> 
> My workflow are to build icedtea out of tree, I usually do something
> like this:
> 
> hg clone http://icedtea.classpath.org/hg/icedtea
> cd icedtea
> ./autogen.sh
> cd ..
> mkdir icedtea-build
> cd icedtea-build
> ../icedtea/configure
> make
> 
> after the build finish then I fix things in the icedtea-build/openjdk dir
> with fixes in place then i get back to the icedtea-build dir,
> removes any blocking stamp file and restart the build.
> cd icedtea-build
> rm stamps/icedtea.stamp
> make
> 
> personally i use a tool named quilt to easily keep track of my
> changes on the openjdk src dir so that i can quickly create patches
> without having to maintain a backup openjdk src tree to diff
> against.

I've worked with quilt before. Perhaps I should use that as well.

> if i have made something worthwhile then i try file it upstream and
> possibly file a identical patch for IcedTea that contains the sun
> bug number, by doing so enables us to easily keep track when a
> upstream patch ends up in the next openjdk release or get
> backported.

Thanks for the input!

Cheers,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20100602/d07c9525/attachment.bin