+++ 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/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121001000510.gk24...@stoneboat.aleph1.co.uk
