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.)
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
