* Russ Allbery:
> Seriously, though, I think the above only tests things out to the degree
> that Autoconf would already be warning about no default specified for
> cross-compiling, yes? Wouldn't you have to at least cross-compile from a
> system with one endianness and int size to a system with a different
> endianness and int size and then try to run the resulting binaries to
> really see if the package would cross-compile?
Is this really necessary? I would think that a LD_PRELOADed DSO which
prevents execution of freshly compiled binaries would be sufficient to
catch the most obvious errors.
If configure is broken, you can still bypass it and manually write a
config.h. Even I can remember the days when this was a rather common
task, even when you were not cross-compiling.
> It's not just that it's perceived as hard. It's that it's perceived as
> hard *and* obscure.
Well, it's hard to keep something working which you cannot test
reliably. I think it would be pretty straightforward to support some
form of cross-compiling for the software I currently maintain
(especially if I go ahead and write that GCC patch for exporting
structure layout and compile-time constants), but there's no point in
doing so if it's not requested by users, I cannot test it as part of
the release procedures, and anybody who needs a binary can typically
cross-compile it without much trouble anyway ("vi config.h ; gcc
*/*.o").
