Re: failure of cross-compilation detection on BlueGene/L

[Steven G. Johnson]

Christian Rössel wrote:
> I don't think that this is a workaround.

Being documented and a workaround are not mutually exclusive: just 
because it is documented that you can override a check doesn't mean that 
it is okay if the check doesn't work the way it is supposed to.  You 
could use the same excuse to ignore bugs in a large number of autoconf 
tests, since many tests have a documented way to override the results 
(e.g. with environment variables.).

Specifying --host but not --build is documented to enter 
cross-compilation mode if executables don't run.  Many users rely on 
this behavior.   Having the check for whether executables work give 
misleading results on Blue Gene is a bug in the check.

If we don't want --host without --build to work, autoconf should exit 
with an error in that case.  (This seems like a bad idea, since forcing 
the user to specify --build is obnoxious and error-prone when 
config.guess can almost always guess the build system.)

> Therefore I'm not sure if my macro will be general enough to be included 
> in config.guess. But a macro 
> AC_SET_HOST_FOR_CROSS_COMPILE_SUPERCOMPUTERS will be useful for many 
> applications.

So, all packages that you might potentially want to cross-compile onto 
supercomputers, from guile to libpng to fftw, are supposed to add this 
macro to their configure.ac files?  That doesn't seem very scalable, and 
it will have the side effect of breaking those packages when the user 
attempts to compile them for the front-end nodes.  It seems much more 
reasonable to use the documented --host method for cross-compiling (plus 
specifying CC etcetera since supercomputers use nonstandard compiler 
names and often give the user a choice among several compilers), the 
same as cross-compiling on any other system.

Steven