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

[Ralf Wildenhues]

<http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/11711>

Hi Steven,

* Steven G. Johnson wrote on Sat, Jun 06, 2009 at 03:03:23AM CEST:
> 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.

Thanks for the report.  In fact, we've encountered this already, see
e.g., this thread
<http://thread.gmane.org/gmane.comp.gnu.libtool.general/10061>
but haven't done much about it.  (Cc:ed the people from that thread.)

One simple but a bit ugly workaround would be to
  ./configure cross_compiling=yes

> As you may or may not know, some of the major supercomputers these days  
> (Cray XT3 and IBM BlueGene) require cross-compiling

Yep.  I hope to get access to one in a couple of months.

>       checking whether we are cross compiling... no

> 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.

Yep.

> 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.)

How effective and efficient would such a test be?  IOW, are we sure
writing to a file is sufficient for all current (and maybe the future)
BG versions and other cross compilation setups to detect them as such?
OTOH, can we be reasonably sure that this works with all emulators we
might care about not to be seen as cross setups?  (wine seems to be fine
with this.)

> 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.

Sounds like a good idea.

> 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.

Barring above questions, I think this is a good idea.  I have no idea
how a good testsuite addition that wouldn't limit itself to BG only
would look like.  Actually, given the lack of a host triplet, I wouldn't
even know how one for BG would look like.

> 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.)

It matters not as the host alias you pass to --host, but definitely for
macros like those from Libtool which decide things based on $host.  In
the other thread, powerpc-bgp-linux seemed like a sensible thing.  But
anyway it would be rather important that somebody goes and allocates a
name with the address@hidden people and a way to recognize the
system, and that users then stick to creating compilers with those
settings.

Otherwise users will keep complaining even after we've fixed autotools.

Cheers,
Ralf