[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: build-essential in cross-environments



On Fri, 13 Feb 2009 12:29:53 +0000
Wookey <wookey@wookware.org> wrote:

> > > 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.
> 
> 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).

Good idea. As you mentioned, these packages are the exception so it
does make sense to treat them as exceptions.

> 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

OK.

> 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.

I'll be flagging all such packages currently in Crush during the Code
Audit and hoping to get relevant fixes into the Debian packages. This
could include the addition of the xcontrol file with an appropriate
line indicating that the package needs a native compiler as well as a
cross-compiler.

We could simply re-use Build-Depends-Tools: by adding build-essential
to the list of tools to be installed, only in xcontrol. Simon?

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpR5mcUP2faz.pgp
Description: PGP signature


Reply to: