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

Re: ./configure in debian/rules

Henrique de Moraes Holschuh wrote:

On Thu, 09 Mar 2006, Hendrik Sattler wrote:
    the type of system on which the package will run.  By default it
    is the same as the build machine.  Specifying it enables the
    cross-compilation mode.
That's insane. However, it doen't say anything about the sitution of --build

Actually, what it was before was completely and utterly broken (not
necessarily in the design, for all I know it was an implementation snafu.
All I know is that cross-compiling with old autoconf is just plain
impossible unless you do practice dark arts).

Now you have this:
HOST: where you are doing the compilation BUILD: where the code being built will run
 TARGET: where code that the code being built will generate when run on a
         BUILD box, will run (for cross-compiling cross-compilers and
	  toolchains, rarely used)

TARGET defaults to BUILD
BUILD defaults to HOST
HOST defaults to whatever (nothing, I think).

Host and Build meant the opposite on autoconf 2.13/automake1.4.  IMHO the
new definitions are much better.

The following is for autoconf 2.5* and newer:

Specify HOST (through --host), and you immediately enter cross-compiling
mode.  Specifiying --host in a Debian maintainer package build when not
crosscompiling is a bug, so don't do it.

For most of the packages, what is so different in cross-compilation in comparison to native?

You must *always* specify BUILD (through --build) when building a Debian
package, it is required by Debian policy, and it MUST be set to the output
of dpkg-architecture -qDEB_BUILD_GNU_TYPE unless overriden.

If you need to specify TARGET then you'd rather better know more than I do
about crosscompiling and how to make that compliant to Debian policy.

and --host are used and both contain the same value.

If both build and host have the same value, you are cross-compiling to the
build architecture, on a host of the same architecture.

This *does* use different compilers for generating production code and
build-tools code, which might be a feature, for all I know.  I'd ask all of
the porters if that is useful before touching it.

Work-around for the compiler could be to ship with symbolic links, e.g.
gcc -> gcc-4.0 -> i686-linux-gcc-4.0

Work around for what?  Not for non-policy compliant, buggy packages, I
presume. Are users somehow being hit by this?

Or do you want to do this to avoid an ifeq..endif block in debian/rules
files that are currently required to detect if --host should be issued to
configure ?

Yes. There are... 25411 Debian packages according to my 'apt-cache stats' and what I would like is to just issue a 'dpkg-buildpackage -aHOST ' on every single one of them and get a .deb file(s) that could be then immediately installed on a HOST machine. Yes, I understand that some packages do require special handing (binutils, gcc, glibc, linux-kernel-{image,headers}), but this number should
be limited to a (well-documented) minimal subset.

As I've indicated earlier, Debian is in fact quite close to this wet dream of mine, it just misses on a small number of annoying items such as '--host' and complications w.r.t. endless ifeq...endif blocks
for uClibc or Dietlibc modifications to the CC command line in debian/rules.

I don't know about all of you guys, but for embedded systems this is quite a pre-requisite I suppose: the ability to do automated cross-compiles of a complete system. Debian was supposed to host most archs after all, yes? Shouldn't we expend more effort in co-existance of all these architectures?

Pjotr Kourzanov

Reply to: