You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2010/06/12 21:07:04 UTC
Bumping autoconf AC_PREREQ to 2.60?
On Friday 11 June 2010, Ruediger Pluem wrote:
> > Modified: httpd/httpd/trunk/configure.in
> > URL:
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/configure.in?rev=
> > 951893&r1=951892&r2=951893&view=diff
> > ================================================================
> > ============== --- httpd/httpd/trunk/configure.in (original)
> > +++ httpd/httpd/trunk/configure.in Sun Jun 6 16:54:51 2010
> > @@ -170,6 +170,9 @@ dnl PCRE and for our config tests will b
> >
> > AC_PROG_CC
> > AC_PROG_CPP
> >
> >
> > +dnl Try to get c99 support for variadic macros
> > +AC_PROG_CC_C99
> > +
>
> This test is only present since autoconf >= 2.60.
> Since 2.59 is still delivered with RedHat 4 / 5 this does not work
> there, but the error is non fatal.
This means it is not a good idea to run buildconf on RH4/5, but a
configure created somewhere else with autoconf 2.60 should work fine.
So this mainly affects httpd developers.
We can either bump AC_PREREQ to 2.60, making it impossible to run
buildconf on RH4/5, or we can include the code for AC_PROG_CC_C99
(about 200 lines) from autoconf 2.60 in httpd's build system. The
current state seems like a bad idea, because of the potential to ship
a broken configure in release tarballs.
Preferences? Is anyone here developing on RHEL?
Re: Bumping autoconf AC_PREREQ to 2.60?
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/13/2010 02:16 PM, Rainer Jung wrote:
> On 13.06.2010 13:29, Ruediger Pluem wrote:
>>
>>
>> On 06/12/2010 09:07 PM, Stefan Fritsch wrote:
>>> On Friday 11 June 2010, Ruediger Pluem wrote:
>>>>> Modified: httpd/httpd/trunk/configure.in
>>>>> URL:
>>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/configure.in?rev=
>>>>> 951893&r1=951892&r2=951893&view=diff
>>>>> ================================================================
>>>>> ============== --- httpd/httpd/trunk/configure.in (original)
>>>>> +++ httpd/httpd/trunk/configure.in Sun Jun 6 16:54:51 2010
>>>>> @@ -170,6 +170,9 @@ dnl PCRE and for our config tests will b
>>>>>
>>>>> AC_PROG_CC
>>>>> AC_PROG_CPP
>>>>>
>>>>>
>>>>> +dnl Try to get c99 support for variadic macros
>>>>> +AC_PROG_CC_C99
>>>>> +
>>>> This test is only present since autoconf>= 2.60.
>>>> Since 2.59 is still delivered with RedHat 4 / 5 this does not work
>>>> there, but the error is non fatal.
>>>
>>> This means it is not a good idea to run buildconf on RH4/5, but a
>>> configure created somewhere else with autoconf 2.60 should work fine.
>>> So this mainly affects httpd developers.
>>>
>>> We can either bump AC_PREREQ to 2.60, making it impossible to run
>>> buildconf on RH4/5, or we can include the code for AC_PROG_CC_C99
>>> (about 200 lines) from autoconf 2.60 in httpd's build system. The
>>> current state seems like a bad idea, because of the potential to ship
>>> a broken configure in release tarballs.
>>>
>>> Preferences? Is anyone here developing on RHEL?
>>
>> I do so partly. This is why I came across this :-). What does
>> AC_PROG_CC_C99
>> really do? Not that I am suggesting to remove this call from configure.in
>> but what does it do? Does it change compiler parameters such that the
>> compiler
>> is switched into C99 mode? If yes isn't gcc by default?
>> So if this is true my idea would be if it would be possible to just call
>> AC_PROG_CC_C99 if autoconf is>= 2.60.
>
> I'm jumping in here:
>
> -- Macro: AC_PROG_CC_C99
> If the C compiler is not in C99 mode by default, try to add an
> option to output variable `CC' to make it so. This macro tries
> various options that select C99 on some system or another,
> preferring extended functionality modes over strict conformance
> modes. It considers the compiler to be in C99 mode if it handles
> `_Bool', `//' comments, flexible array members, `inline', signed
> and unsigned `long long int', mixed code and declarations, named
> initialization of structs, `restrict', `va_copy', varargs macros,
> variable declarations in `for' loops, and variable length arrays.
>
> After calling this macro you can check whether the C compiler has
> been set to accept C99; if not, the shell variable
> `ac_cv_prog_cc_c99' is set to `no'.
>
> More concrete it tries to compile a c99 program using the given CC and
> optionally with the flags -std=gnu99 -std=c99 -c99 -AC99 -xc99=all
> -qlanglvl=extc99 until it eventually works. Then it adds the needed flag
> to CC.
>
> I'm using gcc 4.1.2 and there the macro adds -std=gnu99 to CC in
> build/config_vars.mk.
>
> Stefan: The discussion thread I cited also contains the info how to use
> the directive only if it exists:
>
> ifdef([AC_PROG_CC_C99], [AC_PROG_CC_C99])
+1 to this solution.
-0.5 on importing the code for AC_PROG_CC_C99 in configure.in
Regards
Rüdiger
Re: Bumping autoconf AC_PREREQ to 2.60?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 14 June 2010, William A. Rowe Jr. wrote:
> On 6/13/2010 7:33 AM, Stefan Fritsch wrote:
> > If we want to support autoconf 2.59, it seems much easier to just
> > backport the autoconf macro. And in that way, non-gcc users would
> > benefit as well.
>
> Please report back on the licensing of that macro.
You are right. Autoconf licensing exception covers only "output of
Autoconf" which the macros are not. Therefore the macros are GPL and
cannot be included into httpd. I will instead implement a warning that
a newer version of autoconf is recommended.
Re: Bumping autoconf AC_PREREQ to 2.60?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/13/2010 7:33 AM, Stefan Fritsch wrote:
>
> If we want to support autoconf 2.59, it seems much easier to just
> backport the autoconf macro. And in that way, non-gcc users would
> benefit as well.
Please report back on the licensing of that macro.
Re: Bumping autoconf AC_PREREQ to 2.60?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sun, 13 Jun 2010, Rainer Jung wrote:
> I think Stefan needs uses C99 in include/http_log.h via variadic macros
> (__VA_ARGS__). There, if the compiler is C99, the call to the log function is
> surrounded with an "if" checking the log level first (for efficiency). If the
> compiler is not C99, then it will jump always into the log function and only
> check the log level there.
Exactly.
>
> gcc when not used in C99 mode has another idiom for variadic macros, see e.g.
>
> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Variadic-Macros.html#Variadic-Macros
>
> But that way is not standardized.
If we want to support autoconf 2.59, it seems much easier to just backport
the autoconf macro. And in that way, non-gcc users would benefit as well.
Re: Bumping autoconf AC_PREREQ to 2.60?
Posted by Rainer Jung <ra...@kippdata.de>.
On 13.06.2010 13:29, Ruediger Pluem wrote:
>
>
> On 06/12/2010 09:07 PM, Stefan Fritsch wrote:
>> On Friday 11 June 2010, Ruediger Pluem wrote:
>>>> Modified: httpd/httpd/trunk/configure.in
>>>> URL:
>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/configure.in?rev=
>>>> 951893&r1=951892&r2=951893&view=diff
>>>> ================================================================
>>>> ============== --- httpd/httpd/trunk/configure.in (original)
>>>> +++ httpd/httpd/trunk/configure.in Sun Jun 6 16:54:51 2010
>>>> @@ -170,6 +170,9 @@ dnl PCRE and for our config tests will b
>>>>
>>>> AC_PROG_CC
>>>> AC_PROG_CPP
>>>>
>>>>
>>>> +dnl Try to get c99 support for variadic macros
>>>> +AC_PROG_CC_C99
>>>> +
>>> This test is only present since autoconf>= 2.60.
>>> Since 2.59 is still delivered with RedHat 4 / 5 this does not work
>>> there, but the error is non fatal.
>>
>> This means it is not a good idea to run buildconf on RH4/5, but a
>> configure created somewhere else with autoconf 2.60 should work fine.
>> So this mainly affects httpd developers.
>>
>> We can either bump AC_PREREQ to 2.60, making it impossible to run
>> buildconf on RH4/5, or we can include the code for AC_PROG_CC_C99
>> (about 200 lines) from autoconf 2.60 in httpd's build system. The
>> current state seems like a bad idea, because of the potential to ship
>> a broken configure in release tarballs.
>>
>> Preferences? Is anyone here developing on RHEL?
>
> I do so partly. This is why I came across this :-). What does AC_PROG_CC_C99
> really do? Not that I am suggesting to remove this call from configure.in
> but what does it do? Does it change compiler parameters such that the compiler
> is switched into C99 mode? If yes isn't gcc by default?
> So if this is true my idea would be if it would be possible to just call
> AC_PROG_CC_C99 if autoconf is>= 2.60.
I'm jumping in here:
-- Macro: AC_PROG_CC_C99
If the C compiler is not in C99 mode by default, try to add an
option to output variable `CC' to make it so. This macro tries
various options that select C99 on some system or another,
preferring extended functionality modes over strict conformance
modes. It considers the compiler to be in C99 mode if it handles
`_Bool', `//' comments, flexible array members, `inline', signed
and unsigned `long long int', mixed code and declarations, named
initialization of structs, `restrict', `va_copy', varargs macros,
variable declarations in `for' loops, and variable length arrays.
After calling this macro you can check whether the C compiler has
been set to accept C99; if not, the shell variable
`ac_cv_prog_cc_c99' is set to `no'.
More concrete it tries to compile a c99 program using the given CC and
optionally with the flags -std=gnu99 -std=c99 -c99 -AC99 -xc99=all
-qlanglvl=extc99 until it eventually works. Then it adds the needed flag
to CC.
I'm using gcc 4.1.2 and there the macro adds -std=gnu99 to CC in
build/config_vars.mk.
Stefan: The discussion thread I cited also contains the info how to use
the directive only if it exists:
ifdef([AC_PROG_CC_C99], [AC_PROG_CC_C99])
I think Stefan needs uses C99 in include/http_log.h via variadic macros
(__VA_ARGS__). There, if the compiler is C99, the call to the log
function is surrounded with an "if" checking the log level first (for
efficiency). If the compiler is not C99, then it will jump always into
the log function and only check the log level there.
gcc when not used in C99 mode has another idiom for variadic macros, see
e.g.
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Variadic-Macros.html#Variadic-Macros
But that way is not standardized.
Regards,
Rainer
Re: Bumping autoconf AC_PREREQ to 2.60?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sun, 13 Jun 2010, Ruediger Pluem wrote:
> On 06/12/2010 09:07 PM, Stefan Fritsch wrote:
>> On Friday 11 June 2010, Ruediger Pluem wrote:
>>>> Modified: httpd/httpd/trunk/configure.in
>>>> URL:
>>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/configure.in?rev=
>>>> 951893&r1=951892&r2=951893&view=diff
>>>> ================================================================
>>>> ============== --- httpd/httpd/trunk/configure.in (original)
>>>> +++ httpd/httpd/trunk/configure.in Sun Jun 6 16:54:51 2010
>>>> @@ -170,6 +170,9 @@ dnl PCRE and for our config tests will b
>>>>
>>>> AC_PROG_CC
>>>> AC_PROG_CPP
>>>>
>>>>
>>>> +dnl Try to get c99 support for variadic macros
>>>> +AC_PROG_CC_C99
>>>> +
>>> This test is only present since autoconf >= 2.60.
>>> Since 2.59 is still delivered with RedHat 4 / 5 this does not work
>>> there, but the error is non fatal.
>>
>> This means it is not a good idea to run buildconf on RH4/5, but a
>> configure created somewhere else with autoconf 2.60 should work fine.
>> So this mainly affects httpd developers.
>>
>> We can either bump AC_PREREQ to 2.60, making it impossible to run
>> buildconf on RH4/5, or we can include the code for AC_PROG_CC_C99
>> (about 200 lines) from autoconf 2.60 in httpd's build system. The
>> current state seems like a bad idea, because of the potential to ship
>> a broken configure in release tarballs.
>>
>> Preferences? Is anyone here developing on RHEL?
>
> I do so partly. This is why I came across this :-). What does AC_PROG_CC_C99
> really do? Not that I am suggesting to remove this call from configure.in
> but what does it do? Does it change compiler parameters such that the compiler
> is switched into C99 mode? If yes isn't gcc by default?
> So if this is true my idea would be if it would be possible to just call
> AC_PROG_CC_C99 if autoconf is >= 2.60.
Yes, that's what it does, and no gcc still defaults to c89 by default (I
am using gcc 4.4). Not having c99 will not cause any real functional
problems for httpd. The created code will probably be slightly slower and
the use of APLOG_MAX_LOGLEVEL is not possible without it. So, it's
definitely not perfect to use autoconf 2.59 but for some people, it may
still be preferable to having to install a new autoconf.
I don't have 2.59 installed anywhere to test right now. If the lack of
AC_PROG_CC_C99 just causes a warning, that may be acceptable. Or we may
print a more readable warning that autoconf 2.60 is recommended using the
IFDEF method outlined by Rainer. But I don't want to spend much energy for
special handling of 2.59. If we want to support 2.59, we should just
include the code for AC_PROG_CC_C99 in our configure script.
Re: Bumping autoconf AC_PREREQ to 2.60?
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/12/2010 09:07 PM, Stefan Fritsch wrote:
> On Friday 11 June 2010, Ruediger Pluem wrote:
>>> Modified: httpd/httpd/trunk/configure.in
>>> URL:
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/configure.in?rev=
>>> 951893&r1=951892&r2=951893&view=diff
>>> ================================================================
>>> ============== --- httpd/httpd/trunk/configure.in (original)
>>> +++ httpd/httpd/trunk/configure.in Sun Jun 6 16:54:51 2010
>>> @@ -170,6 +170,9 @@ dnl PCRE and for our config tests will b
>>>
>>> AC_PROG_CC
>>> AC_PROG_CPP
>>>
>>>
>>> +dnl Try to get c99 support for variadic macros
>>> +AC_PROG_CC_C99
>>> +
>> This test is only present since autoconf >= 2.60.
>> Since 2.59 is still delivered with RedHat 4 / 5 this does not work
>> there, but the error is non fatal.
>
> This means it is not a good idea to run buildconf on RH4/5, but a
> configure created somewhere else with autoconf 2.60 should work fine.
> So this mainly affects httpd developers.
>
> We can either bump AC_PREREQ to 2.60, making it impossible to run
> buildconf on RH4/5, or we can include the code for AC_PROG_CC_C99
> (about 200 lines) from autoconf 2.60 in httpd's build system. The
> current state seems like a bad idea, because of the potential to ship
> a broken configure in release tarballs.
>
> Preferences? Is anyone here developing on RHEL?
I do so partly. This is why I came across this :-). What does AC_PROG_CC_C99
really do? Not that I am suggesting to remove this call from configure.in
but what does it do? Does it change compiler parameters such that the compiler
is switched into C99 mode? If yes isn't gcc by default?
So if this is true my idea would be if it would be possible to just call
AC_PROG_CC_C99 if autoconf is >= 2.60.
Regards
Rüdiger
Re: Bumping autoconf AC_PREREQ to 2.60?
Posted by Rainer Jung <ra...@kippdata.de>.
On 12.06.2010 21:07, Stefan Fritsch wrote:
> On Friday 11 June 2010, Ruediger Pluem wrote:
>>> Modified: httpd/httpd/trunk/configure.in
>>> URL:
>>> http://svn.apache.org/viewvc/httpd/httpd/trunk/configure.in?rev=
>>> 951893&r1=951892&r2=951893&view=diff
>>> ================================================================
>>> ============== --- httpd/httpd/trunk/configure.in (original)
>>> +++ httpd/httpd/trunk/configure.in Sun Jun 6 16:54:51 2010
>>> @@ -170,6 +170,9 @@ dnl PCRE and for our config tests will b
>>>
>>> AC_PROG_CC
>>> AC_PROG_CPP
>>>
>>>
>>> +dnl Try to get c99 support for variadic macros
>>> +AC_PROG_CC_C99
>>> +
>>
>> This test is only present since autoconf>= 2.60.
>> Since 2.59 is still delivered with RedHat 4 / 5 this does not work
>> there, but the error is non fatal.
>
> This means it is not a good idea to run buildconf on RH4/5, but a
> configure created somewhere else with autoconf 2.60 should work fine.
> So this mainly affects httpd developers.
>
> We can either bump AC_PREREQ to 2.60, making it impossible to run
> buildconf on RH4/5, or we can include the code for AC_PROG_CC_C99
> (about 200 lines) from autoconf 2.60 in httpd's build system. The
> current state seems like a bad idea, because of the potential to ship
> a broken configure in release tarballs.
>
> Preferences? Is anyone here developing on RHEL?
No problem for me.
2.59 is 6.5 years old, 2.60 4 years. Most recent is 2.65. The last time
there was discussion about this (Nov 2008)
http://marc.info/?t=122787193500002&r=1&w=2
the result seems to have been to recommend 2.61.
Regards,
Rainer