[Peter Kourzanov]
For most of the packages, what is so different in cross-compilation
in comparison to native?
Whether or not 'configure' believes it can use tests of the form "try
compiling and running this little program to see what it does". If it
is cross-compiling, it is forced to skip such tests and use
predetermined default answers.
Note that this can produce nefarious little bugs, if the defaults
aren't correct for your target architecture. Note also that not all
configure scripts are given these default answers - if they aren't, you
get a warning from autoconf about not supporting cross compilation, and
I *believe* --host fails entirely.
There are also many packages which build _and run_ utilities as part of
the build process. Three of my packages do this, though in two cases
it's Debian-specific, so could be edited without much difficulty. Most
packages do not distinguish between compiler-for-the-host-system and
compiler-for-the-target-system (what the Linux kernel makefiles call
"HOSTCC" and "CC"). So those will require significant hacking in
upstream configure scripts and makefile to teach them to detect, and
use, two separate compilers.
Also, debian/rules must make sure not to run any testsuites when cross-
compiling. This is generally not hard, but it *is* an extra thing to
have to fix.
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.
Of the six or so packages I'm involved with, three of them need more
than just '--host'. (And two of the others are arch:all, so there's no
need to cross-compile them anyway.) If that's representative, you're
looking at a *lot* of work by a *lot* of people to realise your dream.
Well, that or a *lot* of work by you, to write and submit patches for
all these packages.