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

Re: "but ./configure makes it look so easy", or why cross compiling isn't always trivial

Peter Samuelson wrote:

[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.

Yes, sure. But all of that is hidden behind the ./configure, why should Debian package management
be concerned with these differences?

And even then, why can't I run these little tests remotely with e.g., rsh? Assuming that I already
have an initial working environment on the host... ;-)

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.

All true.

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.
This is a major problem for cross-compiling the whole distribution. And this is the problem I
would like seeing solved.

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.
Yes. But if I can convince maintainers then I suppose this can become *less* work for a *lot* of

Reply to: