[ On Tuesday, April 16, 2002 at 17:08:31 (-0700), Greywolf wrote: ]
> Subject: Re: Cross-build doesn't work i386->sparc
>
> It could be done, but it would be a hack gross enough to make a Linux
> hacker puke. It involves chroots and things...my mind is whirring, but
> my plate's full, too. Wonder which of my projects is gonna win this
> one.
It's a lot easier than that actually, with the right tools at hand,
though if you've looked in enough detail at what it's taken to make
NetBSD cross-compile successfully then you'll see that it does take a
lot of care and discipline.
Well written programs making _VERY_ careful use of GNU Autoconf (and
either using GNU Automake or strictly following the GNU Coding Standards
w.r.t. makefiles, or even carefully using GNU Make directly), are
potentialy cross-compilable now, though it's _extremely_ easy to screw
up. Most of the macros which support cross-compiling leave the
parameters necessary for successful support as optional. Eg. this
explanation from the Autoconf manual regarding AC_TRY_RUN():
Try to provide a pessimistic default value to use when
cross-compiling makes run-time tests impossible. You do this by
passing the optional last argument to `AC_TRY_RUN'. `autoconf' prints
a warning message when creating `configure' each time it encounters a
call to `AC_TRY_RUN' with no ACTION-IF-CROSS-COMPILING argument given.
You may ignore the warning, though users will not be able to configure
your package for cross-compiling. A few of the macros distributed with
Autoconf produce this warning message.
To configure for cross-compiling you can also choose a value for
those parameters based on the canonical system name (*note Manual
Configuration::). Alternatively, set up a test results cache file with
the correct values for the host system (*note Caching Results::).
This advice to give pessimistic default values for cross-compiles is
very likely to trip up a system like pkgsrc which tries to very
carefully predict and control the system's configuration so that it can
ensure the build produces the desired results. A package might build
fine in a native host build, but fail to produce a functionally
identical package for a different CPU simply because this pessimism
turns off a (perhaps necessary) feature that's seen as available in a
native host build. Unless the given test can be faked out with a
pre-configured set of cached test results, or controlled with explicit
command-line parameters, it will not be possible to successfully
cross-build a package in a way that's usable for pgksrc.
Of course there's also the issue of testing the cross-build. Lots of
packages fail to use Autoconf carefully enough to work, even if they
take advantage of all the necessary machinery provided by Automake (and
they don't accidentally over-ride it with local hacks that break it).
If the package maintainer/author hasn't actually tested cross builds
they probably won't work first time out. The small test packages I
maintain that I've used as learning and testing examples for the GNU
Auto* tools are good examples of packages that make quite careful use of
Auto* but which have never been tested with cross-builds by their
maintainer! ;-)
Not so long ago I did go through the effort of at least testing a VPATH
build of one of my "example" packages, and I found all sorts of
show-stopper bugs (most in what should have been simple Automake
compatible extensions to the makefile.am). It may now work for a
different target CPU assuming the cross-compiler used works properly,
but it's just a very simple single program with a few source files and
manual pages (and no use of AC_TRY_RUN()), so there's probably not a lot
more that could go wrong, especially if VPATH is actually avoided! :-),
something pkgsrc could easily do no matter how many targets are built by
one top-level invocation of 'make'. Not so many packages are that
simple and straight forward though.
After my experience with making even a VPATH build work in one of my own
Auto*'ed packages, and after further reading of the Autoconf manual, and
based on my having read and modified a large number and variety of
configure.in files, I now think Todd's estimation of 30% is very
generous, if not impossibly optimistic! ;-)
--
Greg A. Woods
+1 416 218-0098; <gwoods@acm.org>; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>