27500
Comment:
|
27913
|
Deletions are marked like this. | Additions are marked like this. |
Line 244: | Line 244: |
|| check || DebianBug:733038 || || | |
Line 259: | Line 260: |
|| lcms2 || DebianBug:717839 || || | |
Line 273: | Line 275: |
|| ocl-icd || DebianBug:732821 || || | |
Line 561: | Line 564: |
* texinfo * check * guile-2.0 * highlight * gobject-introspection * systemd * gnutls28 * wget * ijs * libmng * diffstat * sharutils * gstreamer0.10 * x11proto-composite * libxcomposite * db-defaults * libxinerama * jasper * gdk-pixbuf * atk1.0 * libxrandr |
Contents
'arm64' is the Debian port name for the 64-bit ARMv8 architecture, referred to as 'aarch64' in upstream toolchains (GNU triplet aarch64-linux-gnu)
Hardware (that actually works) is just becoming available in October 2013. Debian has not yet secured access to any, so anyone that can help there should get in touch with Wookey wookey@debian.org. The port was started (by ARM and Linaro working with the community in commendable fashion) long before hardware was available so that there would be something to run when it arrives.
Hardware, emulators and models
Arm64 hardware is starting to become available in Q42013. Debian does not yet have access to any.
Arm64 qemu emulation (user-space only) became available in October 2013. This is much faster than the model for building software, but can't be used for kernel-space things like bootloader/kernel work. See Qemu Rootfs below for details.
There is a (non-free, free beer) 'Foundation Model' simulator which can be used to run arm64 code, which is available here
Much of the work packagers need to worry about is updating autoconf, multiarch and cross-build fixes, with a few actual arm64 changes here and there, and doesn;t actually need a model or emulator.
This is the first non-x86 self-bootstrapped Debian port: first 150 packages cross-built using build-profiles to untangle cyclic build-dependencies.
Status
(last updated: Nov 2013)
The initial port was done entirely as cross-build using Ubuntu raring packages as multiarch and the cross-toolchains were more advanced there than in Debian, and Debian was frozen for Wheezy. The resulting image and updates were then used to natively build most of Saucy once real hardware that worked was available. Then that image was used (in Qemu) to natively build a Debian buildd image.
Underway: Ubuntu Saucy and Trusty are 3/4 built (30,000 binaries) for arm64. The missing stuff is largely unported languages (haskell, mono, ruby, go, etc). Debian unstable is being bootstrapped (500 binaries built). Detailed status is below.
There are crosstoolchains built for Raring/Saucy/Trusty. Debian cross-toolchains are being worked on.
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 2012. In Oct/Nov/Dec a quantal-based archive of base packages was built. In Jan 2013 the effort was switched to raring to take advantage of cross-build fixes, multiarch improvements, libc and arm64 updates going in there.
Bootstrap package repos are here.
Current cross-buildability for arm64 is tracked on this status page. Native buildability is tracked at http://qa.ubuntuwire.org/ftbfs/arm64.html.
Pre-built Rootfs
qemu rootfs
Debian: unstable debootstrap+build-essential suitable for use with arm64 qemu (88MB)
Ubuntu: Ubuntu saucy chroot (68MB), suitable for use with arm64 qemu (qemu-arm64 (static) is installed inside it).
See Arm64Qemu for details of building QEMU for arm64 and setting it up.
There is a script to enabled sbuild builds using this chroot, overlayed with all currently available Debian packages.
Using The Foundation model
See https://wiki.debian.org/Arm64Port/raringbootstrap#Raring_rootfs_for_Foundation_model
Bug tracking
Please tag all arm64/aarch64-specific bugs 'arm64' (user=debian-arm@lists.debian.org, tag=arm64 - ) in the BTS (see bugs.debian.org/usertags for instructions), or in launchpad.
Here is an example (assuming you have a patch file, and a body template file)
reportbug $package -V $version -A $patchfile --src --subject "Add arm64 support" --tag patch --pseudo-header 'User: debian-arm@lists.debian.org' --pseudo-header 'Usertag: arm64' --no-tags-menu --severity normal --body-file $template
Here is the current list of arm64 Debian bugs
Here is the current list of arm64 Ubuntu bugs
Upstream-relevant bugs should be filed in the linaro-aarch64 bug tracker to avoid distro duplication of effort. In this case, file bugs in the Debian BTS as well, then link to them in the Linaro tracker.
Repository
Raring, and unstable armv8 bootstrap repos have been set up here. These contain current state of play for modified tools, sources, cross-tools, and packages built for arm64. Notable packages include eglibc2.16, gcc-4.7, linux-source, arm64-cross-toolchain-base, gcc-4.7-aarch64-linux-gnu, dpkg (with build profile support), multiarch versions of perl and python2.7. A quantal chroot was used for initial work but is now (Dec 2012) frozen/abandonned.
You should just be able to add that repo and apt-get install crossbuild-essential-arm64 to get a working cross environment. If build and host arch packages have got out of sync this won't work, which happens often in raring and unstable.
Cross Toolchain
Before anything useful can happen dpkg needs to have arm64 support. This was done in v1.16.4
Toolchain 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.
Toolchain Bootstrap Issues
Quantal bootstrap
The initial arm64 packaged toolchain was done in Ubuntu Quantal, as the first release where multiarch crossbuilding basically worked. The details of this are documented on toolchain/BootstrapIssues#Quantal.
Raring bootstrap
Easier than quantal as all the base porting has already been done. However not quite as easy as one might like. arm64-cross-toolchain-base was updated with some fixes/updates from the armhf/armel-c-t-b packages. Binutils and linux-libc-dev headers were straightforward.
But gcc stage1 build fell over first with bugs in gcc-4.7.2-12ubuntu2 (patches that didn't apply, missing arm64 symbols-files). Then with missing bits/predefs.h header when building libgcc. This turned out to be 1091823.
Then the build completed but there was a libgconv.a packaging error for some reason. Updating to gcc-4.7-2-14ubuntu2 seemed to fix that.
Debian bootstrap
The Debian toolchain bootstrap is being attempted fully multiarch, to avoid the above issues with needing a separate libc:arm64 and equivs packages to make everything work. It's also an opportunity to integrate DEB_BUILD_PROFILE boostrap features to make it all nicely automatable, without toolchains being a special case in the archive. This was initially (December 2012) too troublesome, mostly due to new versions of GCC coming out every few days with this stuff being changed. As of gcc-4.7.2-18 onwards ThibG's patches for the toolchain using the multiarch system libraries are integrated so I had another go.
This process is documented on MultiarchCrossToolchains.
Current status is that experiemntal is being used as the stuff in unstable is too old.
binutils and gcc stage1 are built.
The kernel header patches are being updated for 3.8
Building packages
Given a cross-build chroot, in general you should be able to do
apt-get build-dep -aarm64 <package> apt-get source <package> cd <package>-<ver> CONFIG_SITE=/etc/dpkg-cross/cross-config.arm64 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --preserve-env -aarm64
But there are of course some caveats.
Details on setting up an arm64 cross-chroot are given here: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap
There is no libssp (stack protection) support in aarch64 toolchain yet (Nov 2013, https://cards.linaro.org/browse/TCWG-23) so the -fstack-protector will cause an error:
/usr/lib/gcc/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/bin/ld: cannot find -lssp_nonshared /usr/lib/gcc/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/bin/ld: cannot find -lssp
For any package that uses dpkg-buildflags this is easy to fix by setting DEB_BUILD_MAINT_OPTIONS=hardening=-stackprotector You can set this for the whole build chroot if using one (probably best for now), or for a user, or for a build by doing:
DEB_BUILD_MAINT_OPTIONS=hardening=-stackprotector dpkg-buildpackage -aarm64
Better to fix this permanently in /etc/dpkg/buildflags:
STRIP CFLAGS -fstack-protector
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 autoreconfig 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 689613 In many cases dh_autoreconf can be used to fix this without making horrible, unreadable, autofoo patches. Sometimes it's better to use dh_autotools-dev which only updates config.{sub,guess} without re-generating all the configury because this is less invasive. Some packages won't build a second time after dh_autoreconf has poked them around.
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 and more cross-build fixes in Ubuntu, this work was initialy done in a private Quantal-based repo, and later in a raring-tracking repo, but all bugs are either directly filed, or also pushed upstream to Debian.
Quite a few packages need actual changes. Here is a list so far:
Packages that need arm64-related changes
package |
Debian Bug/Fixed version |
Ubuntu Bug/Fixed version |
dpkg |
|
|
autotools |
20120210.1 |
20120210.1 |
binutils |
|
binutils-2.22.90.20120924 |
coreutils |
|
|
gcc |
gcc-4.7-4.7.2-3 |
gcc-4.7-4.7.2-3ubuntu1arm64 1133104 |
eglibc |
690873 2.16-0arm64.1 |
2.16-0ubuntu3 2.17-0ubuntu4 1120810 |
linux |
||
util-linux |
|
|
perl |
https://github.com/codehelp/perl-cross-debian/tree/master/aarch64-linux-gnu |
|
dpkg-cross |
693730 2.6.8 |
2.6.7arm64 |
(cross)-build-essential |
11.6ubuntu4 |
|
gmp |
||
libffi |
3.0.11-2ubuntu1 |
|
libgc |
|
|
klibc |
|
|
libbsd |
|
|
libx11 |
|
|
mesa |
|
|
openssl |
||
xorg |
|
Packages that need crossbuild fixes
package |
Debian Bug |
Ubuntu Bug |
diffutils |
1:3.2-3 |
1:3.2-1ubuntu1 |
tzdata |
|
|
gdbm |
1.8.3-11ubuntu1 |
|
iptables |
1.4.16 |
|
libsemanage |
|
|
db |
|
|
linux |
|
|
sqlite3 |
|
|
packages that need multiarch-related changes
package |
Debian Bug |
Ubuntu Bug |
perl |
|
|
python-2.7 |
|
|
chrpath |
0.14 |
0.14 |
less |
||
check |
||
gettext |
|
|
ed |
|
|
dctrl-tools |
||
indent |
|
|
fdupes |
||
bc |
||
equivs |
||
linux-atm |
|
|
tcl8.5 |
||
autogen |
|
|
netpbm-free |
2:10.0-15ubuntu2 |
|
libxcb |
|
|
pkgconfig |
|
Packages that need changes for eglibc 2.16
package |
Debian Bug |
Ubuntu Bug |
diffutils |
||
tar |
||
gettext |
||
cpio |
||
coreutils |
8.20 |
or eglibc 2.17
gpm |
|
1.20.4-6ubuntu1 |
Packages that needed config.{guess,sub} updates
package |
Debian Bug |
Ubuntu Bug |
acl |
Quantal |
|
check |
|
|
chrpath |
0.14-1ubuntu1 |
|
cloog-ppl |
|
|
coreutils |
Quantal |
|
cpio |
Quantal |
|
db |
Quantal, |
|
dialog |
Quantal |
|
diffstat |
1.55-3ubuntu1 |
|
diffutils |
689617 1:3.2-7 |
1:3.2-7 |
dropbear |
|
|
expat |
Quantal |
|
findutils |
Quantal |
|
gawk |
|
|
gnupg |
|
Quantal |
json-c |
|
|
kbd |
1.15.3-9ubuntu4 |
|
lcms2 |
|
|
libelf |
693996 0.8.13-4~1 |
1082134 0.8.13-3ubuntu1 |
libgpg-error |
Quantal |
|
libnfnetlink |
||
libnih |
Quantal |
|
libsndfile |
|
|
libx11 |
Quantal |
|
libxml2 |
Quantal |
|
libxslt |
Quantal |
|
make-dfsg |
Quantal |
|
mlocate |
0.25-0ubuntu2 |
|
module-init-tools |
Quantal |
|
mpfr4 |
3.1.0-5ubuntu1 |
|
nano |
Quantal |
|
ncurses |
|
Quantal |
ocl-icd |
|
|
patch |
|
Quantal |
pam |
|
|
pcre3 |
|
Quantal |
popt |
|
Quantal |
sed |
|
Quantal |
x11-kbd-utils |
|
Packages that need build profiles
- eglibc (libselinux)
- libselinux (swig, rub2deb)
- glib2.0 (python-dbus)
- dbus (systemd, libdbus-glib, python-dbus)
- db (java, python-all-dev, python3-dev)
- udev (gobject-0introspection)
- libnih
- libsemanage (swig, rub2deb)
- pam (libaudit)
- libidn (gcj-jdk)
- curl
- pango (gobject introspection)
- cracklib2 (python bindings)
- libisl/libcloog
The set of patches for this (in raring) is here: http://people.debian.org/~wookey/bootstrap/patches/
Packages waiting on build-deps
- curl (nss)
- gnupg (curl)
- apt (Gnupg)
Perl
Perl is a bit of a special case. It needs both cross-build support and multiarchifying. Status is being tracked on Multiarch/Perl
Cross-build supprt currently involves creating config files on a host-arch machine, which currently means a model, or creating the files by inspection and comparison with others. A set of arm64 configs has been created from a model run and comparison with armhf and amd64 configs for Debian and arm64 config for openembedded. These are now checked-in to perl-cross-debian. And perl cross-builds successfully with these configs and that version of perl-cross-debian plus its corresponding perl patches.
Meanwhile There is a multiarch branch of perl here: 'ntyni/multiarch-5.14' branch of git://git.debian.org/perl/perl.git which is discussed in this thread: http://lists.debian.org/debian-perl/2012/09/msg00000.html
This builds and works OK, but does not currently cross-build. Merging these two pieces of work to get a cross-buildable, multiarched, arm64, perl is currently underway.
Packages that don't cross build
dialog
Wrong-arch strip run.
fuse
Conflicting 64-bit definitions: 1087757
icu
configure: error: Error! Cross compiling but no --with-cross-build option specified - please supply the path to an executable ICU's build root
libaio
Needs aarch64 system call definitions
libatomic-ops
Needs aarch64 assembly
Packages that are built for jessie
Initial build in debianised saucy chroot
- eglibc (modified with perl fix)
- pcre3
- attr
- acl
- zlib
- hostname
- libsepol
- ifupdown
- insserv
- kmod
- gpm
- ncurses
- bash
- xz-utils
- libpng
- mawk
- makedev
- base-files
- bzip2
- flex
- dpkg
- time
- tar
- diffutils
- cpio
- lsb
- readline5
- python-all
- libselinux (stage1 - to avoid ruby)
- sed
- libonig
- base-passwd
- debianutils
- slang2
- findutils
- gzip
- readline6
- initramfs-tools
- sysvinit
- gzip
- libcap2
- ustr
- gdbm
- cloog
- patch
- grep
- isl
- libusb
- tcl8.6
- cracklib2
- make-dfsg
- mpclib3
- binutils
- db (stage1 to avoid java)
- mpclib3
- mpfr4
- libnfnetlink
- tcl8.5
- tcp-wrappers
- expat
- util-linux
- libtasn1-3
- libgpg-error
- libtasn1-6
- libffi
- perl
- coreutils
- p11-kit
- liblocale-gettext-perl
- libtext-iconv-perl
- libfile-fcntllock-perl
- libalgorithm-diff-xs-perl
- libtext-charwidth-perl
- libxml-libxml-perl
- e2fsprogs
- libgcrypt11
- file
- popt
- libhtml-parser-perl
- libwww-perl
- libnet-ssleay-perl
- libxml2
- dash
- psmisc
- build-essential
- nspr
- unixodbc
- rtmpdump
- gnutls26
- procps
- sqlite3
- libelf (from experimental)
- libidn (patched for nocheck)
- nss
- sensible-utils
- libtool
- libev
- openslp-dfsg
- hesiod
- tzdata
- python-support
- openldap
- glib2.0
- keyutils
- libverto
- libprelude
- krb5
- libcap-ng
- libaudit
- cunit
- curl
- pkg-config
- pam
- shadow
- apt
- gnupg
- debian-archive-keyring
- libsemanage
- manpages
- mimesupport
- debconf
- gcc-4.8
- libtimedate-perl
- gcc-defaults
- debhelper
- x11proto-core
- gettext
- xutils
- x11-proto-kb
- x11-proto-xext
- xtrans
- xcb-proto
- libx11
- libxau
- libxcb
- libxdmcp
- freetype
- ppl1
- libjpeg-turbo
- dbus
- bison
- cryptsetup
- pcsc-lite
- libice
- libsm
- x11proto-render
- libxrender
- libaio
- fontconfig
- alsa-lib
- libogg
- libvorbis
- nettle
- lzo2
- libarchive
- libpaper
- jbigkit
- flac
- xft
- libbsd
- libdatrie
- libthai
- chrpath
- jbig2dec
- icu
- libsigsegv
- dnsmasq
- libpthread
- libxslt
- libxt6
- x11proto-fixes
- libxext
- libpciaccess
- xorg
- gawk
- bsdmainutils
- libpipeline
- man-db
- nano
- libsndfile
- openssl
- libgc
- libxmu
- libxxf86vm
- libxdamage
- wayland
- mesa
- tk8.5
- libxpm
- libxaw
- libxkbfile
- x11-xkb-utils
- xauth
- libdrm
- python2.7
- cairo
- bc
- libjpeg
- jade
- xmlto
- lua
- x11proto-scrnsaver
- libxss
- libxi
- freeglut
- tiff
- x11proto-dmx
- libdmx
- libedit
- heimdal
- libibverbs
- lcms2
- qpdf
- ocl-icd
- lcms
- ghostscript
- hwloc
- mpich
- mpi-defaults
- texinfo
- check
- guile-2.0
- highlight
- gobject-introspection
- systemd
- gnutls28
- wget
- ijs
- libmng
- diffstat
- sharutils
- gstreamer0.10
- x11proto-composite
- libxcomposite
- db-defaults
- libxinerama
- jasper
- gdk-pixbuf
- atk1.0
- libxrandr
Packages that fail in qemu
All due to 'unknown instruction' or missing syscalls. Mostly in tests
- bash (actually ghostscript)
gs -sPAPERSIZE=letter -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -sOutputFile=bash.pdf bash.ps unknown insn: 7ee1d400 unallocated encoding at line: 4198 Unknown instruction: 0x7ee1d400
- diffutils (needs nocheck)
- cpio (needs nocheck)
- tar (needs nocheck)
- libidn (nocheck would be good, but not implemented)
- mpfr4 (needs nocheck)
- perl (needs nocheck - 3 tests out of 9000 fail)
- x11proto-core
fails in the build: make[4]: Entering directory /«PKGBUILDDIR»/build/specs'
- GEN x11protocol.html
/usr/bin/xmlto: line 261: [: too many arguments
- GEN x11protocol.txt
/usr/bin/xmlto: line 261: [: too many arguments Can't create config directory (/sbuild-nonexistent/.w3m)!unknown insn: 7ee9d400 unallocated encoding at line: 4198 Unknown instruction: 0x7ee9d400 qemu: uncaught target signal 4 (Illegal instruction) - core dumped /usr/share/xmlto/format/docbook/txt: line 21: 79435 Illegal instruction (core dumped) ${CONVERT} ${ARGS} ${POSTARGS} "${XSLT_PROC$ make[4]: *** [x11protocol.txt] Error 1
Packages with issues
Packages that needed fixes
#util-linux apt-get install automake autopoint libtool # (29Mb of stuff) DEB_BUILD_OPTIONS="parallel=80" dpkg-buildpackage -sa > ../buildlog.util-linux-2.20.1 failedwith:
- CC fdisk-fdiskbsdlabel.o In file included from fdiskbsdlabel.c:62:0: fdiskbsdlabel.h:61:2: error: #error unknown architecture
The fix is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689607
#coreutils apt-get install dh-buildinfo groff gperf bison DEB_BUILD_OPTIONS="parallel=80" dpkg-buildpackage -sa fails to build:
- CC src/factor.o /tmp/ccgzV4MB.s: Assembler messages: /tmp/ccgzV4MB.s:668: Error: operand 3 should be an integer register -- adc x11,x2,0' /tmp/ccgzV4MB.s:681: Error: operand 3 should be an integer register -- adc x2,x11,0' /tmp/ccgzV4MB.s:719: Error: operand 3 should be an integer register -- adc x4,x11,0'
see https://bugzilla.redhat.com/show_bug.cgi?id=917735 and http://gmplib.org:8000/gmp/rev/187b7b1646ee which says this is the same issue as fixed in gmp This is the bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698330 Applying that fix (updated) works.
Build-dependencies that need(ed) fixes
Using dose to see what is multiarch-buildable
Dose 3.1 can analyse build-dependencies for a given package, and understands about cross and multi-arch. It can tell you what is currently buildable given the current state of relevant source and package files. Use 3.1.2 for the --checkonly option and the --defaultedMAforeign option
Install it (it's in the bootstrap tools repo)
sudo apt-get install dose-builddebcheck
- -f shows packages you can't build
- -s shows packages you can build
- -e prints an explanation of what the problem is
- --checkonly checks just one package rather than everything
--defaultedMAforeign uses the Ubuntu apt algorithm (not in wheezy) of assuming all arch:all Build-Deps can be considered Multi-Arch:Foreign
To check
dose-builddebcheck -f --checkonly <package> \ --defaultedMAforeign --deb-native-arch=amd64 --deb-foreign-archs=arm64 --deb-host-arch=arm64 \ /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_quantal_main_binary-amd64_Packages \ /var/lib/apt/lists/people.debian.org_%7ewookey_bootstrap_ubunturepo_dists_quantal-bootstrap_main_binary-amd64_Packages \ /var/lib/apt/lists/people.debian.org_%7ewookey_bootstrap_ubunturepo_dists_quantal-bootstrap_main_binary-arm64_Packages \ /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_quantal_universe_source_Sources | grep source