Ubuntu Wiki

• Launchpad Entry: foundations-lucid-cross-building

• Created: 2009-11-16

• Contributors:

• Packages affected:

Summary

Who's doing this, what approaches are they taking, what gotchas haven't we run into yet, and how can we do this better upstream (autotools improvements)?

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Rationale

This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.

User stories

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

Spec whiteboard

• Merging patches/fixes from ~ubuntu-crossbuild to make packages cross-buildable; which packages / seeds do we care to have xcompilable

• Future of dpkg-cross / cross-compilation and multiarch https://wiki.ubuntu.com/MultiarchCross

• Cross-compiler
  • In main or only in a PPA?
    • eventually in main
  • armel only or other targets as well?
    • mips? powerpc? sh?
  • Wrapped in a single source packages, or multiple ones? (e.g. binutils-armel, gcc-armel etc. or toolchain-armel)
  • sysroot-based or still based on --with-headers/--with-libs
• Mass cross-compilation tool

Notes from session

• Not generally possible for all packages but useful for subsets; typically embedded use cases
• Kernel builds on cross compilation seem to have more errors than package builds
• Should try to merge the ~ubuntu-crossbuild into lucid and keep some packages (the ones we care about for some embedded use cases) cross-buildable
• ~2 months to bootstrap Ubuntu armel architecture (on slightly old hardware)
  • This was shortcutted by using Debian packages for dependencies to help speed up building
  • 3-4 months total to bring it up fully with all packages built with failure rates similar to x86

• https://launchpad.net/~ubuntu-crossbuild/+archive/cross

Use cases

• Not expecting to get to the point of cross-building all of Ubuntu
• External projects with limited package footprints

Standard gotchas

• configure --build/host (use dh_auto_configure or CDBS)
• overriding CC (don't)
• running built binaries during build (can be worked around, but painful)
• gtk-doc (runs binaries for introspection; need to disable gtk-doc for now)
• qemu user mode emulation may cause confusion with syscall differences
• doctor toolchain to reject -I/usr/include, etc?

Cross toolchain

• Last few CodeSourcery toolchains have been subtly broken for building kernel binaries, especially when debugging (optimisation bugs?); also reproduced with mainline gcc

• Compare build=x86,host=arm,target=arm with build=x86,host=x86,target=arm to try to isolate codegen differences
• Need to establish wiki page / Launchpad bug tag with known bugs

CategorySpec