The JDK build system is not currently set up to allow 32-bit builds on 64-bit build hosts - see 7153072. This also impacts a 32-bit cross-compilation build on a 64-bit build host. The problem is in the sun/xawt/Makefile where we compile and run the "sizers" program that generates the sizes.32 or sizes.64 data file for use by the Xawt code. Based on ARCH_DATA_MODEL the logic correctly determines whether it is building sizesr.32.c or sizers.64.c, and generates sizes.32 or sizes.64 accordingly. However sizers.c is compiled with the HOST_CC command and will be built using the default data model for the host compiler. So on 64-bit sizers.c.32 gets built as a 64-bit program and when run produces 64-bit values into the sizes.32 file eg:

 > more gensrc/sun/awt/X11/generator/sizes.32
long 8
int 4
short 2
ptr 8
Bool 4
Atom 8
Window 8

instead of

long 4
int 4
short 2
ptr 4
Bool 4
Atom 4
Window 4

These incorrect sizes cause incorrect address calculations to be used which typically leads to a SEGV

>>> Problem is coming from XToolkit.setupModifiers:
>>>
>>> 1741 try {
>>> 1742 XModifierKeymap modmap = new XModifierKeymap(
>>> 1743 XlibWrapper.XGetModifierMapping(getDisplay()));
>>> 1744
>>> 1745 int nkeys = modmap.get_max_keypermod();
>>> 1746
>>> 1747 long map_ptr = modmap.get_modifiermap();
>>>
>>> map_ptr is invalid address and gets passed to Native.getUbyte, which passes it to
>>> sun.misc.Unsafe.getByte - hence the SEGV.

Any use of the HOST_CC command is potentially at risk here but fortunately this is the only case used when cross-compiling (the other case - in the NIO generators - is skipped when cross-compiling).