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"
> Subject: Re: Getting AC_PROG_CC_C99
> Date: 28 September 2011 12:38:33 GMT+07:00
> To: Reuben Thomas
>
On 09/28/11 01:52, Gary V. Vaughan wrote:
> 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.
The simplest fix would be something like the patch at the end of
this message. This matches common practice anyway
On Tue, 27 Sep 2011, Paul Eggert wrote:
> On 09/27/11 03:31, Philip Hazel wrote:
> > The change looks innocuous to me
>
> I worry that the change could mask the real bug
> (which may lie elsewhere). For example, it could
> be that the previous line's backslash was interpreted
> incorrectly. Can
Paul Eggert wrote:
> The simplest fix would be something like the patch at the end of
> this message.
> diff --git a/modules/stdarg b/modules/stdarg
>
> index 84d3e7b..ab3436e 100644
>
> --- a/modules/stdarg
On 09/28/11 09:45, Bruno Haible wrote:
> If the package's configure.ac already invokes AC_PROG_CC_STDC,
> early on (i.e. usually right after AC_PROG_CC), then gnulib's
> AC_REQUIRE([AC_PROG_CC_STDC])
> will be a no-op.
Ah, sorry, then we're fine as-is, since it's normal practice
to put the AC_PR
On 29 Sep 2011, at 00:58, Paul Eggert wrote:
> On 09/28/11 09:45, Bruno Haible wrote:
>> If the package's configure.ac already invokes AC_PROG_CC_STDC,
>> early on (i.e. usually right after AC_PROG_CC), then gnulib's
>> AC_REQUIRE([AC_PROG_CC_STDC])
>> will be a no-op.
>
> Ah, sorry, then we're f
