Re: could not setup config headers machinery

[Eric Blake]

On 10/23/2010 10:25 AM, Dr. David Kirkby wrote:
> On 10/14/10 09:02 PM, Ralf Wildenhues wrote:

> > > checking for IEEE denormalized values... yes
> > > configure: creating ./config.status
> > > config.status: error: invalid argument: `Makefile.'

> > Can you send 'diff -u' of the two configure files (without above line
> > and with)? Of even of the one with float.h and the one with math.h?
>
>
> Sure. First here's the diff between the configure.ac files

Thanks.

> What is also interesting is the difference between that which looks in
> the math.h file and that which looks in the float.h file:
>
> i.e.
>
> address@hidden:~/gsl-1.14$ diff -u configure.ac.math configure.ac.float
> --- configure.ac.math Sat Oct 23 16:55:44 2010
> +++ configure.ac.float Sat Oct 23 16:54:20 2010
> @@ -197,7 +197,7 @@
> AC_CHECK_DECLS(atanh,,,[#include <math.h>])
> AC_CHECK_DECLS(ldexp,,,[#include <math.h>])
> AC_CHECK_DECLS(frexp,,,[#include <math.h>])
> -AC_CHECK_DECLS([fprnd_t],[],[],[[#include <math.h>]])
> +AC_CHECK_DECLS([fprnd_t],[],[],[[#include <float.h>]])

I'm wondering if we are tripping on some sort of length-based bug (that 
is, in the past, we have evidence where some shells mishandle here-docs 
that contain a ${...} expansion across a page boundary; maybe this is a 
similar case).  If it is indeed a length-based bug, does adding one more 
byte in the <math.h> approach also make the bug appear?

> -AC_CHECK_DECLS([fprnd_t],[],[],[[#include <math.h>]])
> +AC_CHECK_DECLS([fprnd_t],[],[],[[#include  <math.h>]])

And if so, it would be really nice to figure out which here-doc (or 
whatever other length-based problem) we are tripping over, so we can 
hopefully find a way to refactor code to avoid it.

Also, to be clear, what versions of sed and awk are being used, and is 
configure settling on /bin/sh or falling back on a more featured shell 
like bash?

> Could this be a gcc bug, which is actually causing the configure script
> to fail?

Does the config.log give any more evidence on the matter?  In 
particular, what did HAVE_DECL_FPRND_T get set to in confdefs.h?

> The reason I'm thinking this is because it seems to be a gcc bug that
> the fprnd_t is not being defined on the AIX system. If fprnd_t was
> defineded properly, I would not need to be testing for this at all. It
> seems a bug thats it not defined, since it is clearly defined in
> /usr/include/float.h

fprnd_t is a non-standard type, so gcc is within its rights to not 
declare it (although if you haven't raised a gcc bug that their 
<float.h> should #include_next the AIX system <float.h>, now would be a 
good time to do so).  That is, gcc need not provide anything beyond what 
is documented on this page of POSIX:

http://www.opengroup.org/onlinepubs/9699919799/basedefs/float.h.html#tag_13_13

although QoI suggest they should support all extensions also provided by 
the vendor.

> It looks to me like this is a gcc bug, but I'm puzzled why it can result
> in a problem with the autoconf generated script.

As am I.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org