Cross-compiling IcedTea7

[Xerxes Ranby]

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

> 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.
> 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
> 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!

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.

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.
> Thierry
>   
Cheers and have a reat day!
Xerxes