Re: cross-compiling philosophy

[Guido Draheim]

Hi Larry,

I am into the crosscompiling thing a lot, and in fact
the most common targets are embedded platforms which
can not bear a full fledged development environment.
Those could not benefit quite from your proposal
unless they are big enough to run a compiler which
in turn has access to a well-sized filesystem, and
all in all with a full network stack in the system,
and processing power enough to get an answer in
a reasonable roundtrip time. See the problem?

There are quite some provisions within autoconf to
help in crosscompiling, most of the standard tests
work via cache-variables that you could override in
a CONFIG_SITE script. Oh well, that option is not
known all too well. It does help with most of the
smaller crosscompiled applications. And if you have
an application with its own handmade configure-time
run-tests then you need to modify them to pick up
some shell-var (or better a cache-var) to make things
easier for you - and allow you to create multiple
config-site scripts for your various platforms that
you target.

Still, there are few things missing in the autotools
series to support crosscompiling for the better, in
the sense to get away with it and _without_ manually
checking a cache-var file. A lot can be done now
but some things are still missing, and if I had only
time then I'd try to write up some patches myself.
However, I am also one of those who do already have
proper config-site files, so why investing time on
other stuff *sigh*

-- cheers, guido


Larry Doolittle wrote:
> I know this subject keeps coming up.  I hope my
> suggestions are taken as constructive (presumably
> for post-2.58).
>
> I ran into one more package (GNU screen-3.9.15) where
> the authors used autoconf, and made no provision for
> cross-compiling.  In fact, they use many detailed
> run-time tests.  I was able to edit configure.in
> to add ACTION-IF-CROSS-COMPILING arguments (tuned to
> my special case) to their AC_TRY_RUN macros, and got
> myself on the air.  Not very satisfying.
>
> There is an implicit assumption in autoconf that
> people who cross-compile have no way to run the
> executables from within the configure script.  So,
> no provision is made for that possibility.
>
> In my case, and I think for an increasing number of
> developers, my target is a relatively full-featured
> Linux machine.  I have a file system (NFS) shared
> between my development workstation and the embedded
> target.  It's fairly trivial to build in a directory
> that is visible by the target (excuse me, "host"),
> and then on the build machine
>   echo "$HOST_TESTDIR/conftest; echo \$?; exit" | \
>       socket nano4 | tail -1
> to see the exit code from running conftest on the
> host.  Normally I have that NFS directory mounted
> read-only by my host machine, but I could change
> that, so even files created by the program would
> become visible to configure.
>
> If the autoconf community were interested in supporting
> this concept, not many changes would be needed.
> 1. Add a new flag, like "CROSS_RUN_SCRIPT", that
>    defines how to run programs on the host.
> 2. Add new macro AC_TRY_COMMAND_HOST, that uses
>    CROSS_RUN_SCRIPT if cross-compiling, otherwise
>    falls back to AC_TRY_COMMAND.
> 3. Switch from AC_TRY_COMMAND to AC_TRY_COMMAND_HOST
>    in all the right places.
> 4. Change AC_RUN_IFELSE so it only crashes if
>     "$cross_compiling" = yes && "$CROSS_RUN_SCRIPT" = ""
>
> Comments?  If I developed, tested, and submitted a patch,
> would anybody look at it?
>
>        - Larry

--
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)