[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: support for non-standard C compilers (without fopen, FILE*, ...)

From: Ralf Wildenhues
Subject: Re: support for non-standard C compilers (without fopen, FILE*, ...)
Date: Fri, 18 Sep 2009 19:11:20 +0200
User-agent: Mutt/1.5.20 (2009-08-09)

* Steffen Dettmer wrote on Fri, Sep 18, 2009 at 11:49:20AM CEST:
> On Thu, Sep 17, 2009 at 7:53 PM, wrote:
> > * Ralf Wildenhues wrote on Thu, Sep 17, 2009 at 07:50:10PM CEST:
> > > * Steffen Dettmer wrote on Thu, Sep 17, 2009 at 05:12:31PM CEST:
> > > > recent versions check if $CC supports fopen, FILE* and so on. This
> > > > breaks environments that don't have <stdio.h> / libc.a.
> > >
> > > This is a 2.64 regression and has been fixed since in the git tree:
> > > <>
> > Please note that with this workaround, you may again have to work around
> > this bug on systems like BG/L:
> > <>
> Do I understand correctly that this was a temporary change that
> had been undone?

Well yes, a regression is a bug in a newer version that did not exist in
an older version.

> I did not understood the BlueGene thread. It was about to enable
> cross compiling even when --build was forgotten?

When --build is omitted and only --host used, then configure, as
backward compatibility kludge to cater to older Autoconf semantics,
tries to guess whether to enable cross compilation, by trying to run
a compiled program.  If that fails, it enables cross compilation.
The problem on BlueGene was that nontrivial code compiled for the
compute nodes does not run on the compile nodes, but Autoconf's test was
so trivial that it would run, giving an undesirable answer to the tests.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]