Date: Tue, 25 Apr 2000 16:47:12 -0400 (EDT)
From: Pavel Roskin <[EMAIL PROTECTED]>
Tests normally don't require running programs.
I completely agree. But the gap between ``normally don't'' and
``never'' is large.
If you expect broken behaviour you should always test at runtime, unless
maybe it will seriously affect performance.
I agree, but performance does matter.
> I've used tests in the past for things like the correct operation of
> the system call ftime (on some versions of SCO Unix, ftime
> periodically moves backward in time, which totally screwed my code).
This is a different issue. But it is not so much relevant to
cross-compilation as it seens to be.
If you compile the program on a good system and then you run it on a bad
machine, you have a problem. Both machines may have exactly the same
canonical strings, but one of then is, say, HP-UX 10.20 with fixpacks and
another one is vanilla HP-UX 10.20
My approach has always been - if a problem is known to exist on the given
architecture (e.g. sparc) that the workaround should be enabled on all
machines with the same architecture.
Autoconf doesn't deal with portability of binaries.
Do you mean that I should penalize every system which runs on the ix86
because SCO Unix screwed up ftime? That doesn't make sense.
I agree that you should avoid testing based on canonical strings. You
should always do feature tests when possible. That is a basic design
philosophy of autoconf.
Of course, feature tests won't help if the same binary is run on
multiple systems, and only some of the systems have the bug. Clearly
runtime tests are better when possible. But you do the best you can.
> If build == host, I run the test at configure time. If build != host,
Don't compare them. i386-unknown-linux-gnu != i386-unknown-linux-gnu
because different machines run different kernels.
Hmmm. Under the old scheme, if --build was specified, we knew we were
being cross-compiled. I think that is still a safe assumption under
the new scheme. If the two strings are identical, we are not being
cross-compiled. If they are different, we are being cross-compiled.
I guess you are saying that in some cases the strings may be identical
but we still want to act as though we are being cross-compiled? It's
hard for me to think of a case where that would be relevant. Just
stick the version number in the configuration string if you have to.
> I indicate that with a configure variable, and run the test at run
> time. If autoconf outsmarted me by getting confused about whether it
> was building for a different system, a test of that form would return
> invalid results.
That's why I proposed "--cross". If people don't like how Autoconf works,
let's simpify the life for those poor guys with broken systems. People who
know what they are doing will use "--cross" when appropriate.
What does --cross add that we don't already have?
Intermediate program for me is something like kaffeh - generator of
headers for Kaffe, mfmt - generator of help file for MC, generator of
Unicode tables for lynx and so on, i.e. programs that are used in the
build process, not tests.
If you persuade configure that build != host then you have to generate
those tables, help files and headers somewhere else, which is ridiculous
for e.g. i586->i386 cross-compilation.
Not at all. The Makefile simply has to be written correctly. Take a
look at the binutils, for example; they require intermediate programs,
but they build just fine when building with a cross-compiler.
Ian
