[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: Getting AC_PROG_CC_C99
From: |
Gary V. Vaughan |
Subject: |
Fwd: Getting AC_PROG_CC_C99 |
Date: |
Wed, 28 Sep 2011 15:52:52 +0700 |
From a private discussion about preventing CFLAGS getting -std=gnu99 twice,
that leads to a bug report for gnulib and maybe autoconf too...
Begin forwarded message:
> From: "Gary V. Vaughan" <address@hidden>
> Subject: Re: Getting AC_PROG_CC_C99
> Date: 28 September 2011 12:38:33 GMT+07:00
> To: Reuben Thomas <address@hidden>
>
> Hi Reuben,
>
> On 27 Sep 2011, at 20:16, Reuben Thomas wrote:
>
>> According to the Zile commit logs:
>>
>> configury: remove duplicate AC_GNU_SOURCE et al
>>
>> AC_GNU_SOURCE and AC_PROG_CC_C99 are automatically required by gl_INIT,
>> no need to specify them again in configure.ac (which results in running
>> `gcc -std=gnu99 -std=gnu99'.
>>
>> I hasten to add there's nothing going wrong in Zile AFAICS.
>>
>> However, in another project (occurs, as mentioned yesterday), I don't
>> automatically get AC_PROG_CC_C99, even though I'm using gnulib, and
>> definitely have the extensions module in there. I've looked at the
>> configure files (sadly hard to examine as there are no comments
>> telling you which bit was expanded from which configure.ac line), and
>> can't see anything obvious. I've stared at the configure.ac files,
>> natch, and ditto.
>>
>> Any hints? I have also looked at the list of gnulib modules for each
>> project and can't see anything there.
>
> Actually, AC_PROG_CC_C99 is automatically called in autoconf's own macros
> by AC_PROG_CC_STDC (see /usr/share/autoconf/autoconf/c.m4), and it is *that*
> macro that gnulib is hooking automatically. By grepping through the Zile
> m4 directory after bootstrapping I quickly came across this in gnulib-comp.m4:
>
> # Code from module stdarg:
> dnl Some compilers (e.g., AIX 5.3 cc) need to be in c99 mode
> dnl for the builtin va_copy to work. With Autoconf 2.60 or later,
> dnl AC_PROG_CC_STDC arranges for this. With older Autoconf AC_PROG_CC_STDC
> dnl shouldn't hurt, though installers are on their own to set c99 mode.
> AC_REQUIRE([AC_PROG_CC_STDC])
>
> The stdarg module is listed explicitly in Zile's bootstrap.conf module list,
> so that is how Zile gets an expansion of AC_PROG_CC_STDC (and the c99 mode
> setting option tests) for free.
>
> Now, the interesting thing is that if I grep through the gnulib/modules
> directory for AC_PROG_CC_STDC calls, *only* stdarg has it. That strikes me
> as kind of odd. Shouldn't all the C99 related modules be calling at least
> AC_PROG_CC_C99 if not the whole AC_PROG_CC_STDC set?
>
> And that points to another problem, because AC_PROG_CC_STDC is not safe
> to call multiple times, since it adds another --std=gnu99 to CFLAGS every
> time it is invoked (at least the version in my Apple suppied Autoconf-2.61),
> so gnulib should probably also have some multiple expansion protection code
> for at least us poor Mac based devs using Homebrew (untested!!):
>
> dnl make sure we only expand AC_PROG_CC_STDC once
> AC_DEFUN_ONCE([gl_PROG_CC_C99], [
> AC_PROVIDE_IFELSE([AC_PROG_CC_C99],
> [],
> [AC_PROG_CC_C99])m4_define([AC_PROG_CC_C99])])
>
> And then add gl_PROG_CC_C99 to all the C99 modules.
>
>> It's not a big problem, as I can just reinstate AC_PROG_CC_C99 in
>> occurs's configure.ac, but it suggests I'm not understanding
>> something.
>
> Might as well try to fix it right in gnulib though, and maybe in autoconf
> too if the latest release hasn't made it multi-call safe yet.
>
> Cheers,
> --
> Gary V. Vaughan (gary AT gnu DOT org)
- Fwd: Getting AC_PROG_CC_C99,
Gary V. Vaughan <=
- Re: Fwd: Getting AC_PROG_CC_C99, Paul Eggert, 2011/09/28
- Re: Fwd: Getting AC_PROG_CC_C99, Bruno Haible, 2011/09/28
- Re: Fwd: Getting AC_PROG_CC_C99, Paul Eggert, 2011/09/28
- Re: Getting AC_PROG_CC_C99, Gary V. Vaughan, 2011/09/29
- Message not available
- Re: Getting AC_PROG_CC_C99, Paul Eggert, 2011/09/29
- Re: Getting AC_PROG_CC_C99, Bruno Haible, 2011/09/30
- Re: Getting AC_PROG_CC_C99, Paul Eggert, 2011/09/30
- Re: Getting AC_PROG_CC_C99, Andrew W. Nosenko, 2011/09/30
- Re: Getting AC_PROG_CC_C99, Paul Eggert, 2011/09/30