You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2017/10/13 13:19:59 UTC
Tagging 2.4.29 / 2.5.0-{alpha/beta?} today
Is anyone seeing an issue of concern about stability on 2.4.x branch?
Has anyone else looked at Jim's proposed fixes for xcode 9 building
under maintainer mode? A couple-line quick fix to configure.in, that
anyone on OS/X should be able to validate in minutes. The same fix
is already present on APR's branches, which I will tag as well.
I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
period, so that the many proposed enhancements can be examined
by alpha testers and our quick adopters of 2.4.28 can be back on track
by early next week. That should simplify getting some of the more
complex patches backported as necessary, or move us forward
in any case.
Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today
Posted by Jim Jagielski <ji...@jaguNET.com>.
Why lump 2.5.0 into all this?
There is no rational reason to force connect 2.4.29 and 2.5.0
Tag 2.4.29 and leave 2.5.0 alone until people discuss it. Until then
I will veto any foolishness about 2.5.0-whatever.
> On Oct 13, 2017, at 9:19 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Is anyone seeing an issue of concern about stability on 2.4.x branch?
>
> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in <http://configure.in/>, that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.
>
> I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
> period, so that the many proposed enhancements can be examined
> by alpha testers and our quick adopters of 2.4.28 can be back on track
> by early next week. That should simplify getting some of the more
> complex patches backported as necessary, or move us forward
> in any case.
>
>
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'd be +1 on setting -Wno-error=strict-prototypes unconditionally
> On Oct 15, 2017, at 11:52 AM, Rainer Jung <ra...@kippdata.de> wrote:
>
> Am 15.10.2017 um 16:25 schrieb Yann Ylavic:
>> On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung <ra...@kippdata.de> 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&m=147508169616462&w=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)
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Oct 16, 2017 at 10:16 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
>> Am 15.10.2017 um 17:52 schrieb Rainer Jung <ra...@kippdata.de>:
>>
>> 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)
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Oct 16, 2017 at 10:16 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
>> Am 15.10.2017 um 17:52 schrieb Rainer Jung <ra...@kippdata.de>:
>>
>> 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)
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 15.10.2017 um 17:52 schrieb Rainer Jung <ra...@kippdata.de>:
>
> Am 15.10.2017 um 16:25 schrieb Yann Ylavic:
>> On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung <ra...@kippdata.de> 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&m=147508169616462&w=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
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'd be +1 on setting -Wno-error=strict-prototypes unconditionally
> On Oct 15, 2017, at 11:52 AM, Rainer Jung <ra...@kippdata.de> wrote:
>
> Am 15.10.2017 um 16:25 schrieb Yann Ylavic:
>> On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung <ra...@kippdata.de> 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&m=147508169616462&w=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)
Posted by Rainer Jung <ra...@kippdata.de>.
Am 15.10.2017 um 16:25 schrieb Yann Ylavic:
> On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung <ra...@kippdata.de> 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&m=147508169616462&w=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)
Posted by Rainer Jung <ra...@kippdata.de>.
Am 15.10.2017 um 16:25 schrieb Yann Ylavic:
> On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung <ra...@kippdata.de> 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&m=147508169616462&w=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)
Posted by Yann Ylavic <yl...@gmail.com>.
On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung <ra...@kippdata.de> 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&m=147508169616462&w=2
Maybe -Werror is just ignored somehow, because I always compile in
maintainer mode with several gcc versions...
Regards,
Yann.
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Yann Ylavic <yl...@gmail.com>.
On Sun, Oct 15, 2017 at 4:03 PM, Rainer Jung <ra...@kippdata.de> 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&m=147508169616462&w=2
Maybe -Werror is just ignored somehow, because I always compile in
maintainer mode with several gcc versions...
Regards,
Yann.
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Jim,
Am 13.10.2017 um 17:51 schrieb Jim Jagielski:
> Let's recall what is really happening...
>
> In maintainer mode, the build system sets -Werror and -Wstrict-prototypes.
> This means that functions which lack strict prototypes will "fail".
>
> Now note that AC_CHECK_LIB does not worry about generating
> function calls w/ prototypes, so, for example, when checking
> for luaL_newstate, it will fail *even if the function exists*!
> In fact, this is how I 1st observed the issue: mod_lua was
> no longer being included.
>
> 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.
>
> PS: CCing dev@apr since APR also uses AC_CHECK_LIB
I has a look at this. autoconf does generate a line they call a
prototype, but it is not a strict prototype (there's no type information
for the function arguments):
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern "C"
#endif
char luaL_newstate ();
int
main ()
{
return luaL_newstate ();
;
return 0;
}
Directly before the "int main" there's the broken prototype line
char luaL_newstate ();
And in fact the compiler would also complain about
int
main ()
due to the missing "void" for the arguments.
Of all the flags we set in maintainer mode, the combination that lets
the compiler fail is:
-Wstrict-prototypes
-Werror
It fails for me also when using GCC (from 4.1.2 to 7.1.0)! So I think a
clang-specific solution is incomplete.
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?
Regards,
Rainer
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Thank you for this summary!
On Oct 13, 2017 10:51, "Jim Jagielski" <ji...@jagunet.com> wrote:
> Let's recall what is really happening...
>
> In maintainer mode, the build system sets -Werror and -Wstrict-prototypes.
> This means that functions which lack strict prototypes will "fail".
>
> Now note that AC_CHECK_LIB does not worry about generating
> function calls w/ prototypes, so, for example, when checking
> for luaL_newstate, it will fail *even if the function exists*!
> In fact, this is how I 1st observed the issue: mod_lua was
> no longer being included.
>
> 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.
>
> PS: CCing dev@apr since APR also uses AC_CHECK_LIB
>
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Oct 16, 2017 at 3:25 PM, Rainer Jung <ra...@kippdata.de> 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...
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Yann Ylavic <yl...@gmail.com>.
On Mon, Oct 16, 2017 at 3:25 PM, Rainer Jung <ra...@kippdata.de> 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...
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Rainer Jung <ra...@kippdata.de>.
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
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Rainer Jung <ra...@kippdata.de>.
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
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Joe Orton <jo...@redhat.com>.
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.
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Jim,
Am 13.10.2017 um 17:51 schrieb Jim Jagielski:
> Let's recall what is really happening...
>
> In maintainer mode, the build system sets -Werror and -Wstrict-prototypes.
> This means that functions which lack strict prototypes will "fail".
>
> Now note that AC_CHECK_LIB does not worry about generating
> function calls w/ prototypes, so, for example, when checking
> for luaL_newstate, it will fail *even if the function exists*!
> In fact, this is how I 1st observed the issue: mod_lua was
> no longer being included.
>
> 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.
>
> PS: CCing dev@apr since APR also uses AC_CHECK_LIB
I has a look at this. autoconf does generate a line they call a
prototype, but it is not a strict prototype (there's no type information
for the function arguments):
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern "C"
#endif
char luaL_newstate ();
int
main ()
{
return luaL_newstate ();
;
return 0;
}
Directly before the "int main" there's the broken prototype line
char luaL_newstate ();
And in fact the compiler would also complain about
int
main ()
due to the missing "void" for the arguments.
Of all the flags we set in maintainer mode, the combination that lets
the compiler fail is:
-Wstrict-prototypes
-Werror
It fails for me also when using GCC (from 4.1.2 to 7.1.0)! So I think a
clang-specific solution is incomplete.
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?
Regards,
Rainer
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by Joe Orton <jo...@redhat.com>.
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.
Re: AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging
2.4.29 / 2.5.0-{alpha/beta?} today)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Thank you for this summary!
On Oct 13, 2017 10:51, "Jim Jagielski" <ji...@jagunet.com> wrote:
> Let's recall what is really happening...
>
> In maintainer mode, the build system sets -Werror and -Wstrict-prototypes.
> This means that functions which lack strict prototypes will "fail".
>
> Now note that AC_CHECK_LIB does not worry about generating
> function calls w/ prototypes, so, for example, when checking
> for luaL_newstate, it will fail *even if the function exists*!
> In fact, this is how I 1st observed the issue: mod_lua was
> no longer being included.
>
> 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.
>
> PS: CCing dev@apr since APR also uses AC_CHECK_LIB
>
AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 /
2.5.0-{alpha/beta?} today)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Let's recall what is really happening...
In maintainer mode, the build system sets -Werror and -Wstrict-prototypes.
This means that functions which lack strict prototypes will "fail".
Now note that AC_CHECK_LIB does not worry about generating
function calls w/ prototypes, so, for example, when checking
for luaL_newstate, it will fail *even if the function exists*!
In fact, this is how I 1st observed the issue: mod_lua was
no longer being included.
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.
PS: CCing dev@apr since APR also uses AC_CHECK_LIB
AC_CHECK_LIB issues under maintainer mode (Was: Re: Tagging 2.4.29 /
2.5.0-{alpha/beta?} today)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Let's recall what is really happening...
In maintainer mode, the build system sets -Werror and -Wstrict-prototypes.
This means that functions which lack strict prototypes will "fail".
Now note that AC_CHECK_LIB does not worry about generating
function calls w/ prototypes, so, for example, when checking
for luaL_newstate, it will fail *even if the function exists*!
In fact, this is how I 1st observed the issue: mod_lua was
no longer being included.
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.
PS: CCing dev@apr since APR also uses AC_CHECK_LIB
Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today
Posted by Reindl Harald <h....@thelounge.net>.
Am 13.10.2017 um 17:05 schrieb William A Rowe Jr:
> On Oct 13, 2017 08:41, "Stefan Eissing" <stefan.eissing@greenbytes.de
> <ma...@greenbytes.de>> wrote:
>
> > Am 13.10.2017 um 15:19 schrieb William A Rowe Jr
> <wrowe@rowe-clan.net <ma...@rowe-clan.net>>:
> >
> > Is anyone seeing an issue of concern about stability on 2.4.x branch?
>
> Not any more than in previous releases, I think.
>
> > Has anyone else looked at Jim's proposed fixes for xcode 9 building
> > under maintainer mode? A couple-line quick fix to configure.in
> <http://configure.in>, that
> > anyone on OS/X should be able to validate in minutes. The same fix
> > is already present on APR's branches, which I will tag as well.
>
> I build in maintainer mode all the time and use Xcode9 since I
> upgrade to macOS 10.13. Whatever weirdness I encountered and reported
> earlier is gone - I rebuilt my local 2.4.x environment and all seems
> well.
>
> I suspect it works because you first configured APR in maintainer mode,
> and httpd inherits cpp flags?
and why does that happen at all for apr-util and httpd?
that means *you can not* build rpm packages for let say sandybridge on a
machine which has installed apr/apr-util built with -mtune=native on a
Skylake cluster until you first rebuild apr/apr-util which then means
you can't build a httpd package optimized for Skylake until you rebuild
the other both again - that is simply wrong and no other software acts
that way
https://bz.apache.org/bugzilla/show_bug.cgi?id=61417
https://bz.apache.org/bugzilla/show_bug.cgi?id=61418
Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Oct 13, 2017 08:41, "Stefan Eissing" <st...@greenbytes.de>
wrote:
> Am 13.10.2017 um 15:19 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
>
> Is anyone seeing an issue of concern about stability on 2.4.x branch?
Not any more than in previous releases, I think.
> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in, that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.
I build in maintainer mode all the time and use Xcode9 since I
upgrade to macOS 10.13. Whatever weirdness I encountered and reported
earlier is gone - I rebuilt my local 2.4.x environment and all seems
well.
I suspect it works because you first configured APR in maintainer mode, and
httpd inherits cpp flags?
Jim's proposal fixes httpd configured in maintainer mode when a
conventional APR is present, IIUC.
Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 13.10.2017 um 15:19 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
>
> Is anyone seeing an issue of concern about stability on 2.4.x branch?
Not any more than in previous releases, I think.
> Has anyone else looked at Jim's proposed fixes for xcode 9 building
> under maintainer mode? A couple-line quick fix to configure.in, that
> anyone on OS/X should be able to validate in minutes. The same fix
> is already present on APR's branches, which I will tag as well.
I build in maintainer mode all the time and use Xcode9 since I
upgrade to macOS 10.13. Whatever weirdness I encountered and reported
earlier is gone - I rebuilt my local 2.4.x environment and all seems
well.
> I'll proceed to tag 2.5.0, and 2.4.29 after a couple hour comment
> period, so that the many proposed enhancements can be examined
> by alpha testers and our quick adopters of 2.4.28 can be back on track
> by early next week. That should simplify getting some of the more
> complex patches backported as necessary, or move us forward
> in any case.
Must have missed any 2.5.0 discussion. Do we have any fixes in the pipe
that cannot be in the 2.4.x line? That'd be a shame.
-Stefan
Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'd say we use STATUS to keep track
Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
I've been watching the maintainer mode deliberations on dev@apr with great
interest. I'm also keenly aware of Steffen's concerns, especially since
dropping pcre didn't cause nearly this much trouble.
If we are all on the same page, I'll continue to work through the expat
headache on Monday and others hopefully are close to replacing your OS/X
solve with a more comprehensive solution, even if that means dropping the
I'll considered -Werror patch regression.
I think we all want a regression free and all-platform release finally. If
you want to be the RM, that's great!
Would anyone who is actively reviewing please chime in when you see your
concerns solved, whether these are related to maintainer mode or Win32?
TIA, Jim, and testers.
On Oct 14, 2017 08:41, "Jim Jagielski" <ji...@jagunet.com> wrote:
> OtherBill, I see that 2.4.29 wasn't tagged. Are you still planning on
> doing so? I can T&R on Monday if you like.
>
Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?} today
Posted by Jim Jagielski <ji...@jaguNET.com>.
OtherBill, I see that 2.4.29 wasn't tagged. Are you still planning on
doing so? I can T&R on Monday if you like.