Re: build-essential in cross-environments
+++ Neil Williams [2009-02-13 09:39 +0000]:
> On Fri, 13 Feb 2009 02:43:35 +0000
> Wookey <wookey@wookware.org> 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/
Reply to: