Differences between revisions 3 and 4
Revision 3 as of 2012-10-09 17:15:20
Size: 6873
Editor: wookey
Comment:
Revision 4 as of 2012-10-09 17:16:53
Size: 6895
Editor: wookey
Comment:
Deletions are marked like this. Additions are marked like this.
Line 57: Line 57:
Spend some time tracking down why builds always fail with EI_foo alias to GI_foo errors DebianBug:680439. Turns out to be gcc4.6 vs 4.7 issue, which boils down to pr33763, the patch for which breaks eglibc builds. So this actually needs to be fixed in gcc. Some hassling got this done quickly with a new pr33763 patch to put in gcc. Spend some time tracking down why builds always fail with ''EI_foo aliased to external symbol GI_foo'' errors DebianBug:680439. Turns out to be gcc4.6 vs 4.7 issue, which boils down to pr33763, the patch for which breaks eglibc builds. So this actually needs to be fixed in gcc. Some hassling got this done quickly with a new pr33763 patch to put in gcc.

'arm64' is the Debian port name for the 64-bit ARMv8 architecture, also referred to as 'aarch64' (GNU triplet aarch64-linux-gnu)

There will be no hardware in existence until sometime in 2013 but ARM (via Linaro) are working well with the community and trying to get this port done early so software will exist when there is something to run it on.

Status

Barely started.

Binutils, kernel, gcc and glibc port patches were sent upstream over the summer of 2012, with enough stuff to build a cross-toolchain available by October.

Bug tracking

Please tag all arm64/aarch64-specific bugs 'arm64' in the BTS.

Here is the current list: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-arm@lists.debian.org;tag=arm64

Cross Toolchain

Before anything useful can happen dpkg needs to have arm64 support. This was done in

Bootstrap

First job is to bootstrap a cross-toolchain so other stuff can be built.

This is relatively easy to do from upstream sources either directly or using a framework like ?OpenEmbedded, but to get a Debian-packaged toolchain easily usable in chroots, sbuild etc requires merging the new port with the Debian packaging, which is frankly a PITA.

When starting from scratch multiarch doesn't help you because you need eglibc:arm64 to make aarch64-linux-gnu-gcc and you need aarch64-linux-gnu-gcc to make eglibc:arm64. So you have to do a 3-stage bootstrap.

Ubuntu has (thanks to Linaro) a package to automate the building of fully-bootstrapped compilers for armhf/el so that was munged to make arm64-cross-toolchain-base, and the delighful task of getting everything working was started.

The process is:

  • Make a binutils with aarch64 port and arm64 packaging in so you can build binutils-source
  • Make a kernel with arm64 stuff in so you can build kernel-source
  • Make a gcc with aarch64 gcc port and arm64 packaging in so you can build gcc-source
  • Make an eglibc with aarch64 port and arm64 packaging in so you canbuild eglibc-source
  • Make arm64-cross-toolchain-base with the right runes in it to build:
    • munged linux-libc-dev kernel headers
    • gcc stage1 bare cross c-compiler
    • eglibc stage1 simple libc
    • gcc stage2 compiler and cross-compiler and libraries
    • eglibc stage 2 (full) build
    • gcc stage3 (full) build

Easy peasy.

This work was initially done in Ubuntu due to better multiarch support, availability of *-cross-toolchain-base and newer eglibc.

Bootstrap Issues

Binutils was straightforward as the Quantal package already had aarch64 support and arm64 packaging. It just builds :-)

Linux-source required some work. linux-3.5.0 is current in quantal. Upstream work was on 3.6 and 3.7, although initially posted patches from July were for 3.5. Only headers are needed and base port is not invasive so version isn't too important. Taking the port from Linaro current armv8 tree http://git.linaro.org/gitweb?p=people/omarrmz/linux-aarch64.git;a=summary and adding Debian arm64 packaging in various places had only one bit of hackery needed (remove mention of drivers/irqchip from arm64/kconfig) to get a linux-source package built. The initial patch is here:

eglibc in Ubuntu is 2.15. supplied glibc patches were for trunk and then 2.16. eglibc2.15 does not build with gcc4.7, only 4.6. Initial gcc patches were for trunk and then 4.7. There was no public 4.6 port. eglibc2.16 was not available in Debian or Ubuntu, but there was a set of packaging in alioth, but no actual glibc source. eglibc Debian source layout is, for historical reasons not like upstream so a load of munging is needed to get the right layout. I did this hard way before dicovering the debian rules target to do it for me better. Then remove the gcc4.6 deps and rules-forcing. Add in glibc aarch64 patch and poke it till it applies. Fortunately glibc and eglibc are very similar here. Grok packaging layout and patch-naming scheme. Fix up submitted-fcntl-bits patch which moves AT_ GNU symbols and needs to put them back in again for each arch specifically. Turn off libselinux when building stage1 (on by default for linux in 2.16 packaging) Spend some time tracking down why builds always fail with EI_foo aliased to external symbol GI_foo errors 680439. Turns out to be gcc4.6 vs 4.7 issue, which boils down to pr33763, the patch for which breaks eglibc builds. So this actually needs to be fixed in gcc. Some hassling got this done quickly with a new pr33763 patch to put in gcc.

gcc packaging is complicated. Lots of patches applied for different arches, distros, options. Only the core C, C++ and fortran compliers are supported in initial port, so libssp, libmudflap, go, java, objectiveC, lidquadmath, ada, multilib etc all need to be disabled. pr33763 fix as above in order to even build eglibc stage1.

Next the gcc stage2 build fails with 'cannot find bits/predefs.h'. Some investigation finds that this is due to xgcc looking in the wrong place for lib headers. These are put in debian/tmp/ and a sysroot is set in order to find them, but the headers path given a) doesn't look in the sysroot and b) is for old /usr/<triplet>/include path instead of new multiarch /usr/include/<triplet>:/usr/include path. Work out where to poke this in multiple packaging layers.

https://launchpad.net/ubuntu/+source/armhf-cross-toolchain-base

Package porting

Many packages need no more than config.guess and config.sub updating to build for arm64. autotools got aarch64 support upstream in June 2012. So autotools-dev 20120608.1 has the files needed. However many (most) packages don't autoreconfi on build, or otherwise update those files so they have to be patched. A lot of boring patches were filed with the tag arm64, such as

Because there is no hardware everything needs to be cross-built so cross-building patches are also needed in many packages, and multiarch patches in many build-deps. Due to the Wheezy freeze and thus the more progressed state of multiarchification in Ubuntu, this work was initialy done in a private Quantal-based repo, but all bugs are either directly filed, or also pushed upstream to Debian.

A few packages need actual changes. Here is a list so far:

package

Debian Bug

Ubuntu Bug

dpkg

672408

autotools

From upstream

binutils

gcc

eglibc

linux

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1063895

util-linux

689607

diffutils

perl

Packages that just needed config.{guess,sub} updates:

  • acl
  • coreutils
  • cpio
  • db
  • db-4.8
  • dialog
  • diffutils
  • dropbear
  • expat
  • findutils
  • gnupg
  • libgpg-error
  • libnih
  • make-dfsg
  • module-init-tools
  • nano
  • ncurses
  • patch
  • pcre3
  • popt
  • sed