[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.
Attachment:
signature.asc
Description: Digital signature