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
