[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cross-compiling philosophy
Re: cross-compiling philosophy
Wed, 29 Oct 2003 21:31:58 +0100
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313
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
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
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?
-- guido http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)