Henrique de Moraes Holschuh wrote:
On Thu, 09 Mar 2006, Hendrik Sattler wrote:
`--host=HOST-TYPE'
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.
<rant>
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?
</rant>
Pjotr Kourzanov
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
