failure of cross-compilation detection on BlueGene/L

[Steven G. Johnson]

Hi, I noticed a failure of the "checking whether we are cross  
compiling" on BlueGene/L, where it erroneously decides that it is  
*not* cross-compiling when in fact it *is*.  I'm willing to submit a  
patch for this (my copyright assignment is on file), but first I  
wanted to get some feedback from you guys about the problem and  
solution.

BACKGROUND:

As you may or may not know, some of the major supercomputers these  
days (Cray XT3 and IBM BlueGene) require cross-compiling: the front- 
ends run GNU/Linux, but the actual compute nodes run some half-baked  
pseudo-POSIX-ish minimal OS, so every program that you want to run has  
to be cross-compiled.  (I'm not happy with this situation, but dealing  
with quirky, exotic system software has long been a fact of life in  
supercomputing.)  Hence, cross-compiling to quirky systems has  
suddenly become common in scientific computing, which is unfortunate  
since most scientific users are unfamiliar with cross-compiling in  
theory or in practice.

PROBLEM:

Anyway, I noticed on BlueGene/L that when I specify a --host=powerpc64- 
ibm flag and also give it CC manually (none of these supercomputers  
use the GNU naming conventions for their cross-compilers), it still  
says:

        checking whether we are cross compiling... no

DIAGNOSIS:

I dug into it, and the reason is that, due to some strangeness of  
BlueGene/L, when you cross-compile a trivial program like the one  
returned by AC_LANG_PROGRAM(), the resulting executable actually runs  
on the build system, and hence _AC_COMPILER_EXEEXT_WORKS thinks that  
it is not cross-compiling.

Unfortunately, less-trivial programs will crash on the build host, so  
subsequent AC_TRY_RUN tests often fail, and various problems ensue.   
Most notably, AC_COMPUTE_INT incorrectly uses the runtime version of  
its test which crashes, and hence AC_CHECK_SIZEOF fails.

In particular, on the BlueGene/L, the minimal correct program that  
crashes on the build system due to the cross-compiling seems to be:

int main(void)
{
    FILE *f = fopen("conftest.val","w");
    fclose(f);
    return 0;
}

(Note that the runtime version of AC_COMPUTE_INT writes to a file,  
which is why it fails if cross-compiling is not detected on BlueGene/L.)

Right now, the only way I could find to work around the problem is to  
s/cross_compiling=no/cross_compiling=yes/ in the configure script,  
which is obviously not something that we would want to recommend to  
general users.

PROPOSED SOLUTION:

_AC_COMPILER_EXEEXT should compile a program that creates a file, not  
just an no-op program.

In order to do this in a language-independent way, it will probably  
need to call a new macro _AC_LANG_IO_PROGRAM that returns a language- 
dependent program which creates a file, similar to the above example.

RATIONALE: this should fix the problem on BlueGene, and should be a  
reasonable test on other platforms since autoconf's other macros  
(notably AC_COMPUTE_INT) require that executables can create files  
when not cross-compiling.

I'm willing to write the necessary macros, test them, and submit a  
patch, but I wanted to check with you guys first to see if you are  
happy with my solution or if you have any other suggestions.

Regards,
Steven G. Johnson

PS. We don't really have a good host-triplet for the BlueGene/L.   
Right now, I'm using powerpc64-ibm, which gets expanded to powerpc64- 
ibm-aix by config.sub, but that's not really right as BlueGene is not  
actually running AIX or Linux or any recognizable OS -- it's a custom  
kernel just for BlueGene.  I would recommend adding a powerpc64-ibm- 
bluegene triplet to the list of those recognized by config.guess.   
(Not that it matters so much in practice, because in practice you have  
to specify the compiler names manually to configure anyway.)