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