Launchpad Entry: foundations-lucid-cross-building
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)?
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.
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.
You can have subsections that better describe specific parts of the issue.
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
Should cover changes required to the UI, or specific UI that is required to implement this
Code changes should include an overview of what needs to change, and in some cases even the specific details.
- 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.
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.
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.
- 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
- 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
- In main or only in a PPA?
- 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
- Not expecting to get to the point of cross-building all of Ubuntu
- External projects with limited package footprints
- 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?
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