Re: ./configure in debian/rules

[Peter Kourzanov <peter.kourzanov@xs4all.nl>]

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