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
