Mer/Build/Cross Build
({{Mer}}) |
|||
Line 1: | Line 1: | ||
+ | {{Mer}} | ||
+ | |||
The OBS build farm and local osc builds create an armel chroot to build the packages in. arm tools are installed into the chroot and run under emulation. | The OBS build farm and local osc builds create an armel chroot to build the packages in. arm tools are installed into the chroot and run under emulation. | ||
Line 49: | Line 51: | ||
== mkbaselibs == | == mkbaselibs == | ||
- | |||
- | |||
- |
Latest revision as of 10:30, 22 September 2010
Mer is back : Please visit http://www.merproject.org to learn more about this news. |
The OBS build farm and local osc builds create an armel chroot to build the packages in. arm tools are installed into the chroot and run under emulation.
Using distribution tools rather than a toolchain provides a more consistent build system.
The problem is that this approach is slow.
The OBS engineers identified the applications that represented the greatest load on the build system:
- bash
- bzip2
- dpkg
- gzip
- m4
- make
- perl
And of course:
- gcc
So the intention is to accelerate these binaries.
[edit] Overview
Lets establish a naming convention: native is the architecture of the chroot; host is the architecture of the underlying CPU. Typically native is armel, host is x86.
The approach to solving this problem is to minimise changes from a pure arm build environment. This is achieved by installing both arm and x86 packages; to avoid collisions the x86 packages are installed into /lib-x86 in the chroot and selected binaries in /bin and /usr/bin are moved out of the way and replaced with symlinks to the i586 binaries.
Many x86 packages are unmodified; any paths they use will relate to the main / directory and the config/data files installed by the native package will be used.
Some packages are modified to minimise build times - eg to avoid 64 bit builds; others are modified (eg dpkg) to set the native architecture as a default.
[edit] Shared Libraries
Obviously the host binaries need to link to shared libraries which are not in the normal LDPATH. We don't want to have to rely on environment variables etc so 2 steps are used:
- modify ldlinux.so to look in /lib-x86/lib etc
- modify the rpath value in the ELF header of each replaced binary
This is done by creating a static build of patchelf and modifying the binaries as they are installed.
Typically a modified package has all postinst scripts removed and replaced with something like:
prefix=/lib-x86 $prefix/usr/bin/patchelf --set-rpath $prefix/lib $prefix/usr/bin/make mv /usr/bin/make /usr/bin/make-orig-x86lib ln -s $prefix/usr/bin/make /usr/bin/make
Note that some libraries have an rpath and need to be treated with patchelf.
One problem arises with fakeroot: it modifies the LD_LIBRARY_PATH to look for libfakeroot-XXX.so
This is handled by editing the fakeroot script to append the /lib-x86/ paths in the same way the multi-arch paths are added.
[edit] mkbaselibs
- This page was last modified on 22 September 2010, at 10:30.
- This page has been accessed 6,779 times.