+++ Neil Williams [2009-02-13 09:39 +0000]: > On Fri, 13 Feb 2009 02:43:35 +0000 > Wookey <[email protected]> wrote: > > > I've just realised (making some new cross-chroots) that installing > > build-essential requires you to have a native toolchain installed > > (gcc, g++). > > > > e.g. in etch: > > Depends: libc6-dev | libc-dev, gcc (>= 4:4.1.1), g++ (>= 4:4.1.1), make, > > dpkg-dev (>= 1.13.5) > > > > Now for cross-building that's not really what you want. > > Why? If you're thinking that the build should fail if any process calls > gcc and not $triplet-gcc, then maybe - but that won't work for all > packages (see CC_FOR_BUILD below). Instead, we already have a lintian > check that will parse the architecture of the actual binaries that end > up being packaged and fail if these do not match the claimed > architecture of the package itself. Yes, this only fails the completed > build but we do need gcc in a cross-building chroot, sadly.
Hmm. I was thinking of the case where you are making a 'pure' cross-toolchain chroot; I have just made a set of 4 (i386/amd64-etch/lenny). I know that none of the packages I need to build have annoying native-toolchain dependencies so a native gcc is not required. Thus it would be nice to have a crossbuild-essential package to make installing this sort of thing easier. Doing this makes it easier to catch cross-build problems because any attemtp to incorectly use native deps/toolchain will fail. Packages that _also_ depend on a native toolchain imply the need for build-essential. Unfortunately nothing in the dependencies gives us this info - I think we should try to invent something that does (in xcontrol). Needs a bit of thought - but there is a real difference between packages that build both cross and native binaries and ones that only build cross-things. OpenEmbedded correctly splits such packges into two parts, and in general I think we should strive for that tpp where possible. I can see that for now requiring build-essential in chroots is the easy option, and ameliorating the problems it causes with a lintian check. However for the cross-building of plain Debian packages I don't get those extra lintian checks, so simply not having native toolchains around is helpful. I suppose they could be added - I'll have to take a look. > > I'm wondering > > if the right thing to do is create a crossbuild-essential package > > which depends on gcc-cross and g++-cross, then have our > > cross-packges provide gcc-cross and g++-cross? > > That sounds like a good idea even though we do need to retain gcc (see > below). > > I've been wondering how to do it because we don't have gcc-cross, we > have gcc-$version-$triplet so we'd need either: > > Package: gcc-cross > Depends: gcc-arm-linux-gnu|gcc-arm-linux-gnueabi|... > Architecture: i386 amd64 powerpc I was just thinking of a virtual package (like mail-transport-agent). So any cross-toolchain provides gcc-cross. Trying to include all the existing arches/version as alternatives explicitly is a bad idea. particular toolchains could also provide a virtual gcc-$triplet-cross so 4.1,4.2,4.3 would all satisfy for people who don;t particularly care which they have (in practice I never have yet, since the C++ ABI settled down in gcc3.3 > > Or what happens if our cross packages provide gcc and g++ directly? > > It's true and it satisfies build-essential as-is, but I have a feeling > > that might produce some unexpected effects. Can anyone think of a > > reason why this wouldn't work? > > CC_FOR_BUILD - A number of packages (absolute figures to be determined > but ~ 6 in Crush so far) compile internal tools that need to be executed > during the cross-build. Yes, these are irksome and a PITA but upstreams > think they are cute and cool and generally shiny. These internal tools > need gcc (although I don't know of any so perverse as to need g++). As I say - the correct fix for this is to split such packages into $package and $package-native, but that could be difficult in practice. In general these packages are the exception rather than the rule and I'd like to bear that in mind when designing mechanisms. If we can flag these then we can deal with them - that's the problem to think about. Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
