Difference between revisions of "KR/ARM"
(→Hosting) |
(→User Space QEMU) |
||
Line 11: | Line 11: | ||
====User Space QEMU==== | ====User Space QEMU==== | ||
− | To be able to utilize user space QEMU, we need the target distribution as a directory on the build system, so that we can enter it with "chroot". QEMU in system mode can than be booted on this file system with NFS root. | + | To be able to utilize user space QEMU, we need the target distribution as a directory on the build system, so that we can enter it with "[http://en.wikipedia.org/wiki/Chroot chroot]". QEMU in system mode can than be booted on this file system with NFS root. |
====System QEMU==== | ====System QEMU==== |
Revision as of 08:44, 7 May 2009
OOo has been ported to Linux ARM (armel) a while ago by Caolan McNamara. Creating a OOo for ARM just means building it. I did build it on Ubuntu 9.04 ARM, other distros may work as well ...
Contents
Hosting
Ideally you have a fast ARM based machine, where you install the distro of choice, building OOo just as usual. Unfortunately I did not have any hardware, so I had to build in emulation.
QEMU
Obviously the emulator of choice is QEMU: "QEMU is a generic and open source machine emulator and virtualizer."
QEMU does not only allow system emulation, but also process emulation. The former means, that a whole computer is emulated, including boot-up, user-land, kernel-land, hardware and everything. The latter means, that a program compiled e.g. for ARM may be directly executed on x86 or x64. Most important difference for compilation tasks is the difference in execution speed and available memory. A whole system emulation is reasonable slow, and especially for ARM memory size is limited to 256MB, while user-space (or in-process) emulation does only emulate user land, the kernel and everything else may run natively. This is especially interesting, as it allows to mix emulated binaries with native ones, see "afterburner" for some usage scenarios.
User Space QEMU
To be able to utilize user space QEMU, we need the target distribution as a directory on the build system, so that we can enter it with "chroot". QEMU in system mode can than be booted on this file system with NFS root.
System QEMU
NFS root
Build times
jaunty with "coreutils bzip2 bash tcsh emdebian epm fastjar dpkg" 4:40
After Burner
Emdebian
Using user space QEMU combined with the Emdebian toolchain gives the shortest build times (~6H).
Build Issues
- sal/typesconfig/typesconfig.c: had to patch away #ifdef ... || ARM32 (fix in cmcfixes56 where the actual correct alignments for real hardware is determined)
- ICU needs to not be build with g++ 4.3: ... internal compiler error - used 4.2 instead (optimizing error - g++ 4.3.2 with -O0 works as well)
- dpkg: error processing openoffice.org-ure_1.5.0-3_linux-2.6-arm.deb (--install):
package architecture (arm) does not match system (armel)