Re: thoughts on using multi-arch based cross-building
+++ peter green [2012-09-30 15:34 +0100]:
> I've been attempting to use multi-arch for cross-building packages
> for raspbian (a debian derivative I am working on for armv6
> hardfloat) and run into a few things which I thought i'd share
> and/or ask about.
I've been doing a fair amount of this too. Some results for unstable
and quantal are here:
http://people.linaro.org/~wookey/buildd/
> Build-depends installation:
> apt-get build-dep is fine if you are building an unmodified package
> from a repo but it's of no use if you have modified the
> build-dependencies to make them satisfiable.
Annoying isn't it? This has been irritating me for years.
/usr/lib/pbuilder-satisfydepends-classic is very useful for the
native-build case, but I am not aware of a multiarch-aware tool. A
tool like this should really be in devscripts.
> dpkg-checkbuilddeps doesn't tell me what architecture the packages
> need to be for and i'm not sure it can (since to do so it would need
> to know whether packages that are not installed are multi-arch
> foreign or not).
>
> Does a tool exist that can be told "install the build-depends needed
> to build the debianised source tree in directory x for architecture
> y"? if not IMO such a tool (or a new option in an existing tool)
> needs to be created.
The dose3 tools can produce the same answers as apt for this problem,
and could quite easily be modified to look at a local source package
rather than only at packages files. Johannes Schauer was looking into
doing this a couple of weeks ago. Any joy Johannes?
I don't know how hard it is to get apt have a 'use the source in front
of you instead' option. That would guarantee consistency but is
somewhat antithetical to the way apt works. (all about archives, not
local sources).
> Pkg-config:
> A soloution needs to be found for this, so-far I have worked arround
> by hacking the package to be multi-arch foreign and then manually
> creating the symlink to the crosswrapper but there has to be a
> better soloution.
Yes. So in ubuntu the gcc-defaults-<arch> package produces a trivial
pkg-config-<triplet> package which depends on pkg-config and install
the appropriate symlink.
I don't much like a package for each symlink, even though it's simple.
Discussion at debconf suggested that for debian a cross-support
package should do this sort of thing. Currently dpkg-cross provides
per-arch autoconf variables, so getting it to stick in the pkg-config
link too seems sensible. At some point (after wheezy) it should be
renamed to cross-support and drop it's existing
library-package-mangling functionality.
I have just created (following on from PJ McDermott's GSOC work) a
cross-build-essential source package that makes crossbuild-essential-<arch>
packages to bring in cross-gcc, cross-g++, dpkg-cross (aka
cross-support) pkg-config-<triplet>. That in this PPA:
https://launchpad.net/~linaro-foundations/+archive/cross-build-tools
and needs some dpkg-vendor foo adding to make it right for both debian
and ubuntu.
> Packages that need a specific gcc version:
> Sometimes packages need to be built using a non-default gcc version.
> We would rather they didn't but i'm sure there will always be such
> cases.
>
> Conventionally in such cases I've added a build-depends on
> gcc-<version> version and then set CC to gcc-<version> but this
> obviously isn't suitable for cross-building.
>
> Setting the CC environment variable is easy to fix (set it to
> <triplet>-gcc-<version> which afaict is fine for both native and
> cross building)
it is, and has been since gcc-4.4 in squeeze at least.
> but I can't think of a good and simple soloution to
> the build-dependency problem since the package name for the
> cross-compiler depends on the architecture.
Hmm, I see what you mean. Build-essential brings in 'latest compiler'
and crossbuild-essential bring in 'latest cross-compiler'. Ideally
something would note the native build-dep on a specific not-latest
native compiler and bring in (or at least try to use) the
corresponding cross-compiler. I'm not sure what that something might
be.
I think a good brainstorm is required on this whole subject,
because we have the clang/gcc issue and the cross/native issue and the gcc
version issue which all require 'compiler selection'. I'd like to
think that there was a good way to do this but I'm not at all sure
what is best. Solutions for one of these cases shouldn't break the
others, and I don't think we've achieved that yet.
Default compiler selections is currently messy for toolchains:
_something_ in the system has to set the gcc-<triplet> link to point
at gcc-<version-<triplet>. This is done by gcc-defaults in the native
case and gcc-defaults-<triplet> for ubuntu toolchains, and using
alternatives mechanism for debian toolchains. I have been told why the
gcc-defaults mechanism is preferred over alternatives, but I've
fogotten.
> Arch all development dependency packages:
> In debian there are some development dependency packages, typically
> packages that depend on the latest version of a library. Since these
> packages don't contain anything that is actually architecture
> specific they are usually arch all. One example is tcl-dev.
>
> The problem is that dpkg/apt always treat arch all packages the same
> as packages for the native architecture making these arch all
> packages useless for cross-building.
Right. Such packages need to have an arch set so that
they preserve the required architecture over the transitive dependecy.
See:
http://wiki.debian.org/Multiarch/CrossDependencies#all_vs_any_-dev_packages
> I see two possible soloutions to this
> 1: make those dependency packages arch any. This will take up a bit
> of archive space but since the packages in question are empty anyway
> it shouldn't be too bad.
> 2: introduce a concept of "effective architecture(s)" for arch all packages.
1 is the right answer. Simple, works. The point being that the
'generic-name' -dev package is not really arch all - it's a library
package just like the arch-any package it depends on and thus should
be arch any too. It's just that in a pre-multiarch world the way apt
worked meant tha tit didn't matter.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: