Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

2017-10-16 Thread William A Rowe Jr 
Seems Jim is +0 to back out and I'm +0 to keep. First
strong opinion wins so we can get to tagging :)

Absolute consensus on informing our apr, and httpd
builders what not to pass as CFLAGS, and why.


On Oct 16, 2017 13:58, "William A Rowe Jr"  wrote:

> If the patch has merit on it's own, without being generalized, then I'm
> fine
> with tagging 1.6.1 with the OS/X specific backport included.
>
> Note that the proposed httpd fix is still uneasy about the trunk flavor;
> https://ci.apache.org/builders/httpd-trunk/builds/1202
>
>
>
> On Mon, Oct 16, 2017 at 1:11 PM, Jim Jagielski  wrote:
> > The APR fix just handles macOS w/ Xcode9 or clang 5.0.0.
> > -Werror can be set "externally" and whether or not we should
> > actually die is debatable. But considering that AC_CHECK_LIB
> > will never use function prototypes, the long term solution may be
> > to simply never use that.
> >
> > I'm +0 on removing the check for APRs but we need to
> > document this behavior someplace since it can easily cause
> > unrepeatable builds.
>

Re: buildbot failure in on httpd-trunk

2017-10-16 Thread Yann Ylavic 
On Tue, Oct 17, 2017 at 1:23 AM, Yann Ylavic  wrote:
> On Tue, Oct 17, 2017 at 12:48 AM, William A Rowe Jr  
> wrote:
>> Rainer,
>>
>> https://ci.apache.org/builders/httpd-trunk/builds/1203
>>
>> would you please re-kick this build from a clean svn checkout? I think we 
>> have
>> various mistakes in our exports.c preprocessor that become tangled in any
>> rebuild scenario.
>
> Hmm, not sure, looks like an issue with the "inline" keyword used in
> some system (systemd) header file, and c89.
> According to github, systemd's master branch uses __inline__ there
> instead (which should be fine with gcc's c89), so dunno if we can do
> something like this (when -stdc=c89):
>
> #undef inline
> #define inline __inline__ /* or APR_INLINE? */
> #include 
>
> Nor if it can even work to #undef "inline"...

Looks fixed now: https://ci.apache.org/builders/httpd-trunk/builds/1205

buildbot success in on httpd-trunk

2017-10-16 Thread buildbot 
The Buildbot has detected a restored build on builder httpd-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/httpd-trunk/builds/1205

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: bb_slave6_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'httpd-trunk-on-commit' 
triggered this build
Build Source Stamp: [branch httpd/httpd/trunk] 1812339
Blamelist: ylavic

Build succeeded!

Sincerely,
 -The Buildbot

Re: buildbot failure in on httpd-trunk

2017-10-16 Thread Yann Ylavic 
On Tue, Oct 17, 2017 at 12:48 AM, William A Rowe Jr  wrote:
> Rainer,
>
> https://ci.apache.org/builders/httpd-trunk/builds/1203
>
> would you please re-kick this build from a clean svn checkout? I think we have
> various mistakes in our exports.c preprocessor that become tangled in any
> rebuild scenario.

Hmm, not sure, looks like an issue with the "inline" keyword used in
some system (systemd) header file, and c89.
According to github, systemd's master branch uses __inline__ there
instead (which should be fine with gcc's c89), so dunno if we can do
something like this (when -stdc=c89):

#undef inline
#define inline __inline__ /* or APR_INLINE? */
#include 

Nor if it can even work to #undef "inline"...

Re: buildbot failure in on httpd-trunk

2017-10-16 Thread William A Rowe Jr 
Rainer,

https://ci.apache.org/builders/httpd-trunk/builds/1203

would you please re-kick this build from a clean svn checkout? I think we have
various mistakes in our exports.c preprocessor that become tangled in any
rebuild scenario.


On Mon, Oct 16, 2017 at 8:30 AM, Rainer Jung  wrote:
> Am 16.10.2017 um 11:23 schrieb build...@apache.org:
>>
>> The Buildbot has detected a new failure on builder httpd-trunk while
>> building . Full details are available at:
>>  https://ci.apache.org/builders/httpd-trunk/builds/1199
>>
>> Buildbot URL: https://ci.apache.org/
>>
>> Buildslave for this Build: bb_slave6_ubuntu
>>
>> Build Reason: The AnyBranchScheduler scheduler named
>> 'httpd-trunk-on-commit' triggered this build
>> Build Source Stamp: [branch httpd/httpd/trunk] 1812263
>> Blamelist: rjung
>>
>> BUILD FAILED: failed compile
>
>
> The failure is
>
> In file included from
> /home/buildslave/slave/httpd-trunk/build/include/ap_config.h:184:0,
>  from
> /home/buildslave/slave/httpd-trunk/build/include/httpd.h:44,
>  from util_expr_private.h:20,
>  from util_expr_parse.y:32:
> /home/buildslave/slave/httpd-trunk/build/include/ap_config_auto.h:357:16:
> error: two or more data types in declaration specifiers
>  #define rlim_t int
> ^
> /home/buildslave/slave/httpd-trunk/build/build/rules.mk:207: recipe for
> target 'util_expr_parse.lo' failed
>
> which showed up, because now we actually run maintainer mode with -Werror.
>
> Does anybody know hot e can look at the contantes of
> server/util_expr_parse.c in the buildbot build dir?
>
> Regards,
>
> Rainer
>

Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today

2017-10-16 Thread Jim Jagielski 
I'd say we use STATUS to keep track

Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

2017-10-16 Thread William A Rowe Jr 
If the patch has merit on it's own, without being generalized, then I'm fine
with tagging 1.6.1 with the OS/X specific backport included.

Note that the proposed httpd fix is still uneasy about the trunk flavor;
https://ci.apache.org/builders/httpd-trunk/builds/1202



On Mon, Oct 16, 2017 at 1:11 PM, Jim Jagielski  wrote:
> The APR fix just handles macOS w/ Xcode9 or clang 5.0.0.
> -Werror can be set "externally" and whether or not we should
> actually die is debatable. But considering that AC_CHECK_LIB
> will never use function prototypes, the long term solution may be
> to simply never use that.
>
> I'm +0 on removing the check for APRs but we need to
> document this behavior someplace since it can easily cause
> unrepeatable builds.

Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

2017-10-16 Thread Jim Jagielski 
The APR fix just handles macOS w/ Xcode9 or clang 5.0.0.
-Werror can be set "externally" and whether or not we should
actually die is debatable. But considering that AC_CHECK_LIB
will never use function prototypes, the long term solution may be
to simply never use that.

I'm +0 on removing the check for APRs but we need to
document this behavior someplace since it can easily cause
unrepeatable builds.

Re: svn commit: r1812303 - /httpd/httpd/branches/2.4.x/STATUS

2017-10-16 Thread William A Rowe Jr 
I raised the question of whether the OS/X changes introduced and backported
in APR are still necessary or desired, or if they should be backed out, and
whether this patch, munged for APR_ macros, is needed for apr 1.6.3 tag?

Yann suggests;

On Oct 16, 2017 11:31, "Yann Ylavic"  wrote:

I didn't look at the APR issue still, same one?
At first glance, APR_ADD_GCC_CFLAG doesn't exist, neither does
--maintainer-mode try to set -Werror.
Or am I missing something?

Also, do we want this for APR-1.6 and 1.7? IIRC for instance our use
of readdir[_r]() might trigger warnings with latest linuxes, or was
this addressed?



On Oct 16, 2017 11:19,  wrote:

Author: ylavic
Date: Mon Oct 16 16:19:46 2017
New Revision: 1812303

URL: http://svn.apache.org/viewvc?rev=1812303=rev
Log:
Propose finalized alternative.

Modified:
httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
STATUS?rev=1812303=1812302=1812303=diff

==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Mon Oct 16 16:19:46 2017
@@ -214,6 +214,19 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
   in CTR flow, adding my +1 to note that the patch looks sane.]
  rjung: I think we need this also for GCC, not only recent clang.
 See the dev list discusion about using NOTEST_CFLAGS.
+ ylavic: Consider (and test ;) proposal below instead?
+
+  *) configure.in: Fix maintainer mode with GCC/Clang.
+ Setting -Wstrict-prototypes in combination with -Werror leads to
compiler
+ errors during configure checks (autoconf generates incomplete
prototypes).
+ As suggested by Joe, add --maintainer/debugger-mode's CFLAGS in
+ NOTEST_CFLAGS to avoid interractions with autoconf's AC_LANG_PROGRAM.
+ APACHE_ADD_GCC_CFLAG now also forces -Wno-strict-prototypes for
-Werror
+ to work despite AC_LANG_PROGRAM generating this warning by itself.
+ trunk patch: http://svn.apache.org/r1812263
+  http://svn.apache.org/r1812301
+ 2.4.x patch: svn merge -c 1812263,1812301 ^/httpd/httpd/trunk .
+ +1: ylavic


 PATCHES/ISSUES THAT ARE BEING WORKED

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

2017-10-16 Thread Yann Ylavic 
On Mon, Oct 16, 2017 at 3:25 PM, Rainer Jung  wrote:
> Am 16.10.2017 um 12:31 schrieb Joe Orton:
>>
>> On Fri, Oct 13, 2017 at 11:51:54AM -0400, Jim Jagielski wrote:
>>>
>>> The long and short is that under maintainer mode, we cannot
>>> expect AC_CHECK_LIB to being correct any longer, because
>>> the combination of -Werror and -Wstrict-prototypes means
>>> that any and all functions looked for/checked for using
>>> AC_CHECK_LIB will NOT be found, due to warnings which are
>>> now fatal errors during configure time, even if those
>>> functions DO exist.
>>
>>
>> IMO the correct fix is to add all -W... flags to NOTEST_CFLAGS not
>> CFLAGS so they don't take effect during the configure run at all.  At
>> least I can't think of a good motivation for having compiler warnings
>> enabled when running autoconf tests in general.
>
>
> Good hint, never used that variable.

+1!

> So what about the following patch
> instead: just tried it on trunk and seemed to work fine there.

Slightly modified (see attached), it works for me too.

I just added a second arg to APACHE_ADD_GCC_CFLAG which allows me to:
+  APACHE_ADD_GCC_CFLAG([-Werror], [-Wno-strict-prototypes])

where $2 is also used for AC_LANG_PROGRAM's CFLAGS (before $1), but
will not be added to NOTEST_CFLAGS.
Without this change, -Werror is still not accepted by AC_LANG_PROGRAM for me...
Index: acinclude.m4
===
--- acinclude.m4	(revision 1812289)
+++ acinclude.m4	(working copy)
@@ -960,7 +960,7 @@ YES_IS_DEFINED
 dnl
 dnl APACHE_ADD_GCC_CFLAGS
 dnl
-dnl Check if compiler is gcc and supports flag. If yes, add to CFLAGS.
+dnl Check if compiler is gcc and supports flag. If yes, add to NOTEST_CFLAGS.
 dnl
 AC_DEFUN([APACHE_ADD_GCC_CFLAG], [
   define([ap_gcc_ckvar], [ac_cv_gcc_]translit($1, [-:.=], []))
@@ -967,13 +967,13 @@ AC_DEFUN([APACHE_ADD_GCC_CFLAG], [
   if test "$GCC" = "yes"; then
 AC_CACHE_CHECK([whether gcc accepts $1], ap_gcc_ckvar, [
   save_CFLAGS="$CFLAGS"
-  CFLAGS="$CFLAGS $1"
+  CFLAGS="$CFLAGS $2 $1"
   AC_COMPILE_IFELSE([AC_LANG_PROGRAM()],
 [ap_gcc_ckvar=yes], [ap_gcc_ckvar=no])
   CFLAGS="$save_CFLAGS"
 ])
 if test "$]ap_gcc_ckvar[" = "yes" ; then
-   APR_ADDTO(CFLAGS,[$1])
+   APR_ADDTO(NOTEST_CFLAGS,[$1])
 fi
   fi
   undefine([ap_gcc_ckvar])
Index: configure.in
===
--- configure.in	(revision 1812289)
+++ configure.in	(working copy)
@@ -627,21 +627,17 @@ AC_ARG_ENABLE(load-all-modules,APACHE_HELP_STRING(
 AC_ARG_ENABLE(maintainer-mode,APACHE_HELP_STRING(--enable-maintainer-mode,Turn on debugging and compile time warnings and load all compiled modules),
 [
   if test "$enableval" = "yes"; then
-APR_ADDTO(CPPFLAGS, -DAP_DEBUG)
+APR_ADDTO(NOTEST_CPPFLAGS, -DAP_DEBUG)
 if test "$GCC" = "yes"; then
-  APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith])
-  # Next flag needed, because -Wstrict-prototypes in combination with
-  # -Werror leads to compiler errors during configure checks (autoconf
-  # generates incomplete prototypes).
-  APACHE_ADD_GCC_CFLAG([-Wno-error=strict-prototypes])
+  APR_ADDTO(NOTEST_CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith])
   APACHE_ADD_GCC_CFLAG([-std=c89])
-  APACHE_ADD_GCC_CFLAG([-Werror])
+  APACHE_ADD_GCC_CFLAG([-Werror], [-Wno-strict-prototypes])
   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Wformat])
   APACHE_ADD_GCC_CFLAG([-Wformat-security])
   APACHE_ADD_GCC_CFLAG([-Wunused])
 elif test "$AIX_XLC" = "yes"; then
-  APR_ADDTO(CFLAGS,-qfullpath -qinitauto=FE -qcheck=all -qinfo=pro)
+  APR_ADDTO(NOTEST_CFLAGS,-qfullpath -qinitauto=FE -qcheck=all -qinfo=pro)
 fi
 if test "x$enable_load_all_modules" = "x"; then
   LOAD_ALL_MODULES=yes
@@ -657,9 +653,9 @@ AC_ARG_ENABLE(maintainer-mode,APACHE_HELP_STRING(-
 AC_ARG_ENABLE(debugger-mode,APACHE_HELP_STRING(--enable-debugger-mode,Turn on debugging and compile time warnings and turn off optimization),
 [
   if test "$enableval" = "yes"; then
-APR_ADDTO(CPPFLAGS, -DAP_DEBUG)
+APR_ADDTO(NOTEST_CPPFLAGS, -DAP_DEBUG)
 if test "$GCC" = "yes"; then
-  APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -O0])
+  APR_ADDTO(NOTEST_CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -O0])
   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Werror=declaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Wformat])
@@ -666,7 +662,7 @@ AC_ARG_ENABLE(debugger-mode,APACHE_HELP_STRING(--e
   APACHE_ADD_GCC_CFLAG([-Wformat-security])
   APACHE_ADD_GCC_CFLAG([-Werror=format-security])

Re: buildbot failure in on httpd-trunk

2017-10-16 Thread Yann Ylavic 
On Mon, Oct 16, 2017 at 3:30 PM, Rainer Jung  wrote:
> Am 16.10.2017 um 11:23 schrieb build...@apache.org:
>>
>> The Buildbot has detected a new failure on builder httpd-trunk while
>> building . Full details are available at:
>>  https://ci.apache.org/builders/httpd-trunk/builds/1199
>>
>> Buildbot URL: https://ci.apache.org/
>>
>> Buildslave for this Build: bb_slave6_ubuntu
>>
>> Build Reason: The AnyBranchScheduler scheduler named
>> 'httpd-trunk-on-commit' triggered this build
>> Build Source Stamp: [branch httpd/httpd/trunk] 1812263
>> Blamelist: rjung
>>
>> BUILD FAILED: failed compile
>
>
> The failure is
>
> In file included from
> /home/buildslave/slave/httpd-trunk/build/include/ap_config.h:184:0,
>  from
> /home/buildslave/slave/httpd-trunk/build/include/httpd.h:44,
>  from util_expr_private.h:20,
>  from util_expr_parse.y:32:
> /home/buildslave/slave/httpd-trunk/build/include/ap_config_auto.h:357:16:
> error: two or more data types in declaration specifiers
>  #define rlim_t int
> ^
> /home/buildslave/slave/httpd-trunk/build/build/rules.mk:207: recipe for
> target 'util_expr_parse.lo' failed
>
> which showed up, because now we actually run maintainer mode with -Werror.

Same error here:
configure:30308: checking for rlim_t
configure:30329: gcc -c -g -O0 -fno-strict-aliasing -Wall
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations
-pthread -Wpointer-arith -Wno-error=strict-prototypes -std=c89 -Werror
-Wdeclaration-after-statement -Wformat -Wformat-security -Wunused
-DLINUX -D_REENTRANT -D_GNU_SOURCE -DAP_DEBUG conftest.c >&5
conftest.c:59:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
 main ()
 ^~~~
conftest.c: In function 'main':
conftest.c:61:8: error: unused variable 'spoon' [-Werror=unused-variable]
 rlim_t spoon;
^
cc1: all warnings being treated as errors
configure:30329: $? = 1

So it's starting to be a lot of warnings we'd have -Wno-error in
CFLAGS, Joe's proposal looks better (not really working for me either
for now, but let's discuss it in the other thread).

>
> Does anybody know hot e can look at the contantes of
> server/util_expr_parse.c in the buildbot build dir?

I don't think it's particularly related to ap_expr code (see error
above), it's just that yacc may be using rlim_t somewhere...


Regards,
Yann.

Re: buildbot failure in on httpd-trunk

2017-10-16 Thread Rainer Jung 

Am 16.10.2017 um 11:23 schrieb build...@apache.org:

The Buildbot has detected a new failure on builder httpd-trunk while building . 
Full details are available at:
 https://ci.apache.org/builders/httpd-trunk/builds/1199

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: bb_slave6_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'httpd-trunk-on-commit' 
triggered this build
Build Source Stamp: [branch httpd/httpd/trunk] 1812263
Blamelist: rjung

BUILD FAILED: failed compile


The failure is

In file included from 
/home/buildslave/slave/httpd-trunk/build/include/ap_config.h:184:0,
 from 
/home/buildslave/slave/httpd-trunk/build/include/httpd.h:44,

 from util_expr_private.h:20,
 from util_expr_parse.y:32:
/home/buildslave/slave/httpd-trunk/build/include/ap_config_auto.h:357:16: 
error: two or more data types in declaration specifiers

 #define rlim_t int
^
/home/buildslave/slave/httpd-trunk/build/build/rules.mk:207: recipe for 
target 'util_expr_parse.lo' failed


which showed up, because now we actually run maintainer mode with -Werror.

Does anybody know hot e can look at the contantes of 
server/util_expr_parse.c in the buildbot build dir?


Regards,

Rainer

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

2017-10-16 Thread Rainer Jung 

Am 16.10.2017 um 12:31 schrieb Joe Orton:

On Fri, Oct 13, 2017 at 11:51:54AM -0400, Jim Jagielski wrote:

The long and short is that under maintainer mode, we cannot
expect AC_CHECK_LIB to being correct any longer, because
the combination of -Werror and -Wstrict-prototypes means
that any and all functions looked for/checked for using
AC_CHECK_LIB will NOT be found, due to warnings which are
now fatal errors during configure time, even if those
functions DO exist.


IMO the correct fix is to add all -W... flags to NOTEST_CFLAGS not
CFLAGS so they don't take effect during the configure run at all.  At
least I can't think of a good motivation for having compiler warnings
enabled when running autoconf tests in general.


Good hint, never used that variable. So what about the following patch 
instead: just tried it on trunk and seemed to work fine there. Ut 
changes APACHE_ADD_GCC_CFLAG to operate on NOTEST_CFLAGS instead of 
CFLAGS (the macro currently is only used in places where we IMHO 
actually want that change) and introduces NOTEST_CFLAGS use to configure 
where we handle maintainer mode and debugger mode.


Index: acinclude.m4
===
--- acinclude.m4(revision 1812263)
+++ acinclude.m4(working copy)
@@ -960,7 +960,7 @@
 dnl
 dnl APACHE_ADD_GCC_CFLAGS
 dnl
-dnl Check if compiler is gcc and supports flag. If yes, add to CFLAGS.
+dnl Check if compiler is gcc and supports flag. If yes, add to 
NOTEST_CFLAGS.

 dnl
 AC_DEFUN([APACHE_ADD_GCC_CFLAG], [
   define([ap_gcc_ckvar], [ac_cv_gcc_]translit($1, [-:.=], []))
@@ -973,7 +973,7 @@
   CFLAGS="$save_CFLAGS"
 ])
 if test "$]ap_gcc_ckvar[" = "yes" ; then
-   APR_ADDTO(CFLAGS,[$1])
+   APR_ADDTO(NOTEST_CFLAGS,[$1])
 fi
   fi
   undefine([ap_gcc_ckvar])
Index: configure.in
===
--- configure.in(revision 1812263)
+++ configure.in(working copy)
@@ -627,14 +627,10 @@

AC_ARG_ENABLE(maintainer-mode,APACHE_HELP_STRING(--enable-maintainer-mode,Turn 
on debugging and compile time warnings and load all compiled modules),

 [
   if test "$enableval" = "yes"; then
-APR_ADDTO(CPPFLAGS, -DAP_DEBUG)
+APR_ADDTO(NOTEST_CPPFLAGS, -DAP_DEBUG)
 if test "$GCC" = "yes"; then
-  APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes 
-Wmissing-declarations -Wpointer-arith])

-  # Next flag needed, because -Wstrict-prototypes in combination with
-  # -Werror leads to compiler errors during configure checks (autoconf
-  # generates incomplete prototypes).
-  APACHE_ADD_GCC_CFLAG([-Wno-error=strict-prototypes])
-  APACHE_ADD_GCC_CFLAG([-std=c89])
+  APR_ADDTO(NOTEST_CFLAGS,[-Wall -Wmissing-prototypes 
-Wstrict-prototypes -Wmissing-declarations -Wpointer-arith])

+  #APACHE_ADD_GCC_CFLAG([-std=c89])
   APACHE_ADD_GCC_CFLAG([-Werror])
   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Wformat])
@@ -641,7 +637,7 @@
   APACHE_ADD_GCC_CFLAG([-Wformat-security])
   APACHE_ADD_GCC_CFLAG([-Wunused])
 elif test "$AIX_XLC" = "yes"; then
-  APR_ADDTO(CFLAGS,-qfullpath -qinitauto=FE -qcheck=all -qinfo=pro)
+  APR_ADDTO(NOTEST_CFLAGS,-qfullpath -qinitauto=FE -qcheck=all 
-qinfo=pro)

 fi
 if test "x$enable_load_all_modules" = "x"; then
   LOAD_ALL_MODULES=yes
@@ -657,9 +653,9 @@

AC_ARG_ENABLE(debugger-mode,APACHE_HELP_STRING(--enable-debugger-mode,Turn 
on debugging and compile time warnings and turn off optimization),

 [
   if test "$enableval" = "yes"; then
-APR_ADDTO(CPPFLAGS, -DAP_DEBUG)
+APR_ADDTO(NOTEST_CPPFLAGS, -DAP_DEBUG)
 if test "$GCC" = "yes"; then
-  APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes 
-Wmissing-declarations -Wpointer-arith -O0])
+  APR_ADDTO(NOTEST_CFLAGS,[-Wall -Wmissing-prototypes 
-Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -O0])

   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Werror=declaration-after-statement])
   APACHE_ADD_GCC_CFLAG([-Wformat])
@@ -666,7 +662,7 @@
   APACHE_ADD_GCC_CFLAG([-Wformat-security])
   APACHE_ADD_GCC_CFLAG([-Werror=format-security])
 elif test "$AIX_XLC" = "yes"; then
-  APR_ADDTO(CFLAGS,-qfullpath -qinitauto=FE -qcheck=all -qinfo=pro)
+  APR_ADDTO(NOTEST_CFLAGS,-qfullpath -qinitauto=FE -qcheck=all 
-qinfo=pro)

 fi
   fi
 ])dnl


Regards,

Rainer

gcc error (-Werror=pointer-compare) in trunk util_expr_eval.c

2017-10-16 Thread Rainer Jung 
I get the following error for an old line (r1037504, but now trying 
maintainer-mode):


.../server/util_expr_eval.c: In function 'ap_expr_eval_re_backref':
.../server/util_expr_eval.c:265:63: error: comparison between pointer 
and zero character constant [-Werror=pointer-compare]

 if (!ctx->re_pmatch || !ctx->re_source || *ctx->re_source == '\0' ||
   ^~
.../server/util_expr_eval.c:265:47: note: did you mean to dereference 
the pointer?

 if (!ctx->re_pmatch || !ctx->re_source || *ctx->re_source == '\0' ||
   ^

and indeed re_source is defined as

const char **re_source;

So does the following patch look good (one more level of dereferencing)?

Index: server/util_expr_eval.c
===
--- server/util_expr_eval.c (revision 1812263)
+++ server/util_expr_eval.c (working copy)
@@ -262,7 +262,7 @@
 {
 int len;

-if (!ctx->re_pmatch || !ctx->re_source || *ctx->re_source == '\0' ||
+if (!ctx->re_pmatch || !ctx->re_source || **ctx->re_source == '\0' ||
 ctx->re_nmatch < n + 1)
 return "";


The 2.4 branch looks the same as trunk.

Regards,

Rainer

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

2017-10-16 Thread Joe Orton 
On Fri, Oct 13, 2017 at 11:51:54AM -0400, Jim Jagielski wrote:
> The long and short is that under maintainer mode, we cannot
> expect AC_CHECK_LIB to being correct any longer, because
> the combination of -Werror and -Wstrict-prototypes means
> that any and all functions looked for/checked for using
> AC_CHECK_LIB will NOT be found, due to warnings which are
> now fatal errors during configure time, even if those
> functions DO exist.

IMO the correct fix is to add all -W... flags to NOTEST_CFLAGS not 
CFLAGS so they don't take effect during the configure run at all.  At 
least I can't think of a good motivation for having compiler warnings 
enabled when running autoconf tests in general.

buildbot failure in on httpd-trunk

2017-10-16 Thread buildbot 
The Buildbot has detected a new failure on builder httpd-trunk while building . 
Full details are available at:
https://ci.apache.org/builders/httpd-trunk/builds/1199

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: bb_slave6_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'httpd-trunk-on-commit' 
triggered this build
Build Source Stamp: [branch httpd/httpd/trunk] 1812263
Blamelist: rjung

BUILD FAILED: failed compile

Sincerely,
 -The Buildbot

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

2017-10-16 Thread Yann Ylavic 
On Mon, Oct 16, 2017 at 10:16 AM, Stefan Eissing
 wrote:
>
>> Am 15.10.2017 um 17:52 schrieb Rainer Jung :
>>
>> Nevertheless I would still say that adding "-Wno-error=strict-prototypes" 
>> for any clang and gcc version that supports it would be the correct option. 
>> Then -Werror should automatically get applied again.
>
> +1

+1

Thanks Rainer!

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

2017-10-16 Thread Jim Jagielski 
I'd be +1 on setting -Wno-error=strict-prototypes unconditionally

> On Oct 15, 2017, at 11:52 AM, Rainer Jung  wrote:
> 
> Am 15.10.2017 um 16:25 schrieb Yann Ylavic:
>> On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung  wrote:
>>> 
>>> Why is this happening now? The "-Werror" was backported last December in
>>> r1772330, which was a backport of r1702948 from trunk (May 2015). Maybe
>>> people haven't used maintainer mode since then?
>> During the backport process of r1772330, Jacob noticed that -Werror
>> was not working as expected (see STATUS changes in this commit). He
>> also made a comment on dev@ here:
>> https://marc.info/?l=apache-cvs=147508169616462=2
>> Maybe -Werror is just ignored somehow, because I always compile in
>> maintainer mode with several gcc versions...
> 
> Thanks Yann, I actually only ran gcc with the respective flags. But indeed 
> configure checks for each flag whether it is "working" and the program which 
> gets compiled is:
> 
> int
> main ()
> {
> struct tm tm; tm.tm_gmtoff;
>  ;
>  return 0;
> }
> 
> So since we set -Wstrict-prototypes before, -Werror turns this into
> 
> conftest.c:45:1: error: function declaration isn't a prototype 
> [-Werror=strict-prototypes]
> main ()
> ^~~~
> 
> and -Werror does not get set at all.
> 
> Nevertheless I would still say that adding "-Wno-error=strict-prototypes" for 
> any clang and gcc version that supports it would be the correct option. Then 
> -Werror should automatically get applied again.
> 
> So something like the following (simple) patch should be an improvement for 
> gcc and clang and also fix Jim's problem. Of course since we then would have 
> -Werror enabled probably for the first time for gcc other new problems might 
> show (that will currently only be observable as warnings during maintainer 
> builds).
> 
> Index: configure.in
> ===
> --- configure.in(revision 1812218)
> +++ configure.in(working copy)
> @@ -597,6 +597,7 @@
> if test "$GCC" = "yes"; then
>   APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes 
> -Wmissing-declarations -Wpointer-arith])
>   APACHE_ADD_GCC_CFLAG([-std=c89])
> +  APACHE_ADD_GCC_CFLAG([-Wno-error=strict-prototypes])
>   APACHE_ADD_GCC_CFLAG([-Werror])
>   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
>   APACHE_ADD_GCC_CFLAG([-Wformat])
> 
> Regards,
> 
> Rainer

Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today)

2017-10-16 Thread Stefan Eissing 


> Am 15.10.2017 um 17:52 schrieb Rainer Jung :
> 
> Am 15.10.2017 um 16:25 schrieb Yann Ylavic:
>> On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung  wrote:
>>> 
>>> Why is this happening now? The "-Werror" was backported last December in
>>> r1772330, which was a backport of r1702948 from trunk (May 2015). Maybe
>>> people haven't used maintainer mode since then?
>> During the backport process of r1772330, Jacob noticed that -Werror
>> was not working as expected (see STATUS changes in this commit). He
>> also made a comment on dev@ here:
>> https://marc.info/?l=apache-cvs=147508169616462=2
>> Maybe -Werror is just ignored somehow, because I always compile in
>> maintainer mode with several gcc versions...
> 
> Thanks Yann, I actually only ran gcc with the respective flags. But indeed 
> configure checks for each flag whether it is "working" and the program which 
> gets compiled is:
> 
> int
> main ()
> {
> struct tm tm; tm.tm_gmtoff;
>  ;
>  return 0;
> }
> 
> So since we set -Wstrict-prototypes before, -Werror turns this into
> 
> conftest.c:45:1: error: function declaration isn't a prototype 
> [-Werror=strict-prototypes]
> main ()
> ^~~~
> 
> and -Werror does not get set at all.

Ha, nice catch! ;-)

> Nevertheless I would still say that adding "-Wno-error=strict-prototypes" for 
> any clang and gcc version that supports it would be the correct option. Then 
> -Werror should automatically get applied again.

+1

> So something like the following (simple) patch should be an improvement for 
> gcc and clang and also fix Jim's problem. Of course since we then would have 
> -Werror enabled probably for the first time for gcc other new problems might 
> show (that will currently only be observable as warnings during maintainer 
> builds).
> 
> Index: configure.in
> ===
> --- configure.in(revision 1812218)
> +++ configure.in(working copy)
> @@ -597,6 +597,7 @@
> if test "$GCC" = "yes"; then
>   APR_ADDTO(CFLAGS,[-Wall -Wmissing-prototypes -Wstrict-prototypes 
> -Wmissing-declarations -Wpointer-arith])
>   APACHE_ADD_GCC_CFLAG([-std=c89])
> +  APACHE_ADD_GCC_CFLAG([-Wno-error=strict-prototypes])
>   APACHE_ADD_GCC_CFLAG([-Werror])
>   APACHE_ADD_GCC_CFLAG([-Wdeclaration-after-statement])
>   APACHE_ADD_GCC_CFLAG([-Wformat])
> 
> Regards,
> 
> Rainer