Mailing List Archive

On Mon, Mar 07, 2022 at 04:55:54PM +0100, Stefan Eissing wrote:
> Hi all,
>
> Please find below the proposed release tarball and signatures:
>
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha256: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 *httpd-2.4.53-rc1.tar.gz
> sha512: a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 *httpd-2.4.53-rc1.tar.gz
>
> The SVN candidate source is found at tags/2.4.53-rc1-candidate.

+1 for release and thanks for RMing. Passes test suite on Fedora 35,
RHEL 8, and 9 Beta(ish).

I got a new "may be uninitialized" warning with with the GCC 12 shapshot
used in Fedora 36 (which is still under development and can be
unreliable). I think it's unreachable, if we enter here:

https://github.com/apache/httpd/blob/trunk/modules/lua/lua_request.c#L244

r->remaining must be > 0 and hence length > rpos is guaranteed and the
loop will iterate at least once.

lua_request.c: In function ‘lua_read_body’:
lua_request.c:260:12: error: ‘len_read’ may be used uninitialized [-Werror=maybe-uninitialized]
260 | if (len_read < 0) {
| ^
lua_request.c:247:22: note: ‘len_read’ was declared here
247 | apr_off_t len_read, rpos = 0;
| ^~~~~~~~

On 3/8/22 12:57 PM, Joe Orton wrote:
> On Mon, Mar 07, 2022 at 04:55:54PM +0100, Stefan Eissing wrote:
>> Hi all,
>>
>> Please find below the proposed release tarball and signatures:
>>
>> https://dist.apache.org/repos/dist/dev/httpd/
>>
>> I would like to call a VOTE over the next few days to release
>> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
>> [X] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>
>> The computed digests of the tarball up for vote are:
>> sha256: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 *httpd-2.4.53-rc1.tar.gz
>> sha512: a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 *httpd-2.4.53-rc1.tar.gz
>>
>> The SVN candidate source is found at tags/2.4.53-rc1-candidate.
>
> +1 for release and thanks for RMing. Passes test suite on Fedora 35,
> RHEL 8, and 9 Beta(ish).
>
> I got a new "may be uninitialized" warning with with the GCC 12 shapshot
> used in Fedora 36 (which is still under development and can be
> unreliable). I think it's unreachable, if we enter here:
>
> https://github.com/apache/httpd/blob/trunk/modules/lua/lua_request.c#L244
>
> r->remaining must be > 0 and hence length > rpos is guaranteed and the
> loop will iterate at least once.

I agree, but I am also fine to init len_read to -1 to avoid this. But I think this is not a blocker.
Thanks for bringing it to attention. r1898731.


Regards

Rüdiger

> On Mar 7, 2022, at 10:55 AM, Stefan Eissing <stefan@eissing.org> wrote:
>
> Hi all,
>
> Please find below the proposed release tarball and signatures:
>
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
> [X] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>

Tested:
o macOS 12.2.1 w/ Xcode 13.2.1 / OpenSSL 1.1.1m
o Ubuntu 20.04LTS / OpenSSL 1.1.1m

On Tue, Mar 08, 2022 at 02:01:42PM +0100, Ruediger Pluem wrote:
> > I got a new "may be uninitialized" warning with with the GCC 12 shapshot
> > used in Fedora 36 (which is still under development and can be
> > unreliable). I think it's unreachable, if we enter here:
> >
> > https://github.com/apache/httpd/blob/trunk/modules/lua/lua_request.c#L244
> >
> > r->remaining must be > 0 and hence length > rpos is guaranteed and the
> > loop will iterate at least once.
>
> I agree, but I am also fine to init len_read to -1 to avoid this. But I think this is not a blocker.
> Thanks for bringing it to attention. r1898731.

Nice, thank you. +1 to that for 2.4.x.

Am 07.03.2022 um 16:55 schrieb Stefan Eissing:
> Hi all,
>
> Please find below the proposed release tarball and signatures:
>
> https://dist.apache.org/repos/dist/dev/httpd/
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
>
> The computed digests of the tarball up for vote are:
> sha256: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 *httpd-2.4.53-rc1.tar.gz
> sha512: a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 *httpd-2.4.53-rc1.tar.gz
>
> The SVN candidate source is found at tags/2.4.53-rc1-candidate.
>
> Kind Regards,
> Stefan

Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19)
and RHEL7 (gcc 4.8.2, glibc 2.19) with platform compilers, configure
detects it wants to set -std=gnu11. During make I get a compilation error:

server/util.c:3183:1: error: unknown type name ‘_Thread_local’

The type "_Thread_local" comes from include/httpd.h:

2438 #if defined(__cplusplus) && __cplusplus >= 201103L
2439 #define AP_THREAD_LOCAL thread_local
2440 #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
2441 #define AP_THREAD_LOCAL _Thread_local
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2442 #elif defined(__GNUC__) /* works for clang too */
2443 #define AP_THREAD_LOCAL __thread
2444 #elif defined(WIN32) && defined(_MSC_VER)
2445 #define AP_THREAD_LOCAL __declspec(thread)
2446 #endif
2447 #endif /* ndef AP_NO_THREAD_LOCAL */

It looks like the detection is broken?

Best regards,

Rainer

For anyone thinking about testing rc1, there is a high chance of an rc2 coming soon.

Will announce here,

Stefan

> Am 08.03.2022 um 16:33 schrieb Rainer Jung <rainer.jung@kippdata.de>:
>
>
> Am 07.03.2022 um 16:55 schrieb Stefan Eissing:
>> Hi all,
>> Please find below the proposed release tarball and signatures:
>> https://dist.apache.org/repos/dist/dev/httpd/
>> I would like to call a VOTE over the next few days to release
>> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
>> [ ] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>> The computed digests of the tarball up for vote are:
>> sha256: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 *httpd-2.4.53-rc1.tar.gz
>> sha512: a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 *httpd-2.4.53-rc1.tar.gz
>> The SVN candidate source is found at tags/2.4.53-rc1-candidate.
>> Kind Regards,
>> Stefan
>
> Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19) and RHEL7 (gcc 4.8.2, glibc 2.19) with platform compilers, configure detects it wants to set -std=gnu11. During make I get a compilation error:
>
> server/util.c:3183:1: error: unknown type name ‘_Thread_local’
>
> The type "_Thread_local" comes from include/httpd.h:
>
> 2438 #if defined(__cplusplus) && __cplusplus >= 201103L
> 2439 #define AP_THREAD_LOCAL thread_local
> 2440 #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
> 2441 #define AP_THREAD_LOCAL _Thread_local
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 2442 #elif defined(__GNUC__) /* works for clang too */
> 2443 #define AP_THREAD_LOCAL __thread
> 2444 #elif defined(WIN32) && defined(_MSC_VER)
> 2445 #define AP_THREAD_LOCAL __declspec(thread)
> 2446 #endif
> 2447 #endif /* ndef AP_NO_THREAD_LOCAL */
>
> It looks like the detection is broken?
>
> Best regards,
>
> Rainer

Am 08.03.2022 um 16:33 schrieb Rainer Jung:
>
> Am 07.03.2022 um 16:55 schrieb Stefan Eissing:
>> Hi all,
>>
>> Please find below the proposed release tarball and signatures:
>>
>> https://dist.apache.org/repos/dist/dev/httpd/
>>
>> I would like to call a VOTE over the next few days to release
>> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
>> [ ] +1: It's not just good, it's good enough!
>> [ ] +0: Let's have a talk.
>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>
>> The computed digests of the tarball up for vote are:
>> sha256:
>> 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3
>> *httpd-2.4.53-rc1.tar.gz
>> sha512:
>> a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961
>> *httpd-2.4.53-rc1.tar.gz
>>
>> The SVN candidate source is found at tags/2.4.53-rc1-candidate.
>>
>> Kind Regards,
>> Stefan
>
> Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19)
> and RHEL7 (gcc 4.8.2, glibc 2.19) with platform compilers, configure
> detects it wants to set -std=gnu11. During make I get a compilation error:
>
> server/util.c:3183:1: error: unknown type name ‘_Thread_local’
>
> The type "_Thread_local" comes from include/httpd.h:
>
>   2438  #if defined(__cplusplus) && __cplusplus >= 201103L
>   2439  #define AP_THREAD_LOCAL thread_local
>   2440  #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
>   2441  #define AP_THREAD_LOCAL _Thread_local
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   2442  #elif defined(__GNUC__) /* works for clang too */
>   2443  #define AP_THREAD_LOCAL __thread
>   2444  #elif defined(WIN32) && defined(_MSC_VER)
>   2445  #define AP_THREAD_LOCAL __declspec(thread)
>   2446  #endif
>   2447  #endif /* ndef AP_NO_THREAD_LOCAL */
>
> It looks like the detection is broken?

See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066

On 3/8/22 4:38 PM, Rainer Jung wrote:
> Am 08.03.2022 um 16:33 schrieb Rainer Jung:
>>
>> Am 07.03.2022 um 16:55 schrieb Stefan Eissing:
>>> Hi all,
>>>
>>> Please find below the proposed release tarball and signatures:
>>>
>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>
>>> I would like to call a VOTE over the next few days to release
>>> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
>>> [ ] +1: It's not just good, it's good enough!
>>> [ ] +0: Let's have a talk.
>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>>
>>> The computed digests of the tarball up for vote are:
>>> sha256: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 *httpd-2.4.53-rc1.tar.gz
>>> sha512:
>>> a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 *httpd-2.4.53-rc1.tar.gz
>>>
>>>
>>> The SVN candidate source is found at tags/2.4.53-rc1-candidate.
>>>
>>> Kind Regards,
>>> Stefan
>>
>> Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19) and RHEL7 (gcc 4.8.2, glibc 2.19) with platform
>> compilers, configure detects it wants to set -std=gnu11. During make I get a compilation error:
>>
>> server/util.c:3183:1: error: unknown type name ‘_Thread_local’
>>
>> The type "_Thread_local" comes from include/httpd.h:
>>
>>    2438  #if defined(__cplusplus) && __cplusplus >= 201103L
>>    2439  #define AP_THREAD_LOCAL thread_local
>>    2440  #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
>>    2441  #define AP_THREAD_LOCAL _Thread_local
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>    2442  #elif defined(__GNUC__) /* works for clang too */
>>    2443  #define AP_THREAD_LOCAL __thread
>>    2444  #elif defined(WIN32) && defined(_MSC_VER)
>>    2445  #define AP_THREAD_LOCAL __declspec(thread)
>>    2446  #endif
>>    2447  #endif /* ndef AP_NO_THREAD_LOCAL */
>>
>> It looks like the detection is broken?
>
> See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066

Thanks for the pointer. Does the below fix it?

Index: include/httpd.h
===================================================================
--- include/httpd.h (revision 1898730)
+++ include/httpd.h (working copy)
@@ -2587,7 +2587,9 @@
*/
#if defined(__cplusplus) && __cplusplus >= 201103L
#define AP_THREAD_LOCAL thread_local
-#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
+#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 && \
+ (!defined(__GNUC__) || \
+ __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9))
#define AP_THREAD_LOCAL _Thread_local
#elif defined(__GNUC__) /* works for clang too */
#define AP_THREAD_LOCAL __thread


Regards

Rüdiger

Am 08.03.2022 um 17:06 schrieb Ruediger Pluem:
>
>
> On 3/8/22 4:38 PM, Rainer Jung wrote:
>> Am 08.03.2022 um 16:33 schrieb Rainer Jung:
>>>
>>> Am 07.03.2022 um 16:55 schrieb Stefan Eissing:
>>>> Hi all,
>>>>
>>>> Please find below the proposed release tarball and signatures:
>>>>
>>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>>
>>>> I would like to call a VOTE over the next few days to release
>>>> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
>>>> [ ] +1: It's not just good, it's good enough!
>>>> [ ] +0: Let's have a talk.
>>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>>>
>>>> The computed digests of the tarball up for vote are:
>>>> sha256: 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3 *httpd-2.4.53-rc1.tar.gz
>>>> sha512:
>>>> a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961 *httpd-2.4.53-rc1.tar.gz
>>>>
>>>>
>>>> The SVN candidate source is found at tags/2.4.53-rc1-candidate.
>>>>
>>>> Kind Regards,
>>>> Stefan
>>>
>>> Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc 2.19) and RHEL7 (gcc 4.8.2, glibc 2.19) with platform
>>> compilers, configure detects it wants to set -std=gnu11. During make I get a compilation error:
>>>
>>> server/util.c:3183:1: error: unknown type name ‘_Thread_local’
>>>
>>> The type "_Thread_local" comes from include/httpd.h:
>>>
>>>    2438  #if defined(__cplusplus) && __cplusplus >= 201103L
>>>    2439  #define AP_THREAD_LOCAL thread_local
>>>    2440  #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
>>>    2441  #define AP_THREAD_LOCAL _Thread_local
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>    2442  #elif defined(__GNUC__) /* works for clang too */
>>>    2443  #define AP_THREAD_LOCAL __thread
>>>    2444  #elif defined(WIN32) && defined(_MSC_VER)
>>>    2445  #define AP_THREAD_LOCAL __declspec(thread)
>>>    2446  #endif
>>>    2447  #endif /* ndef AP_NO_THREAD_LOCAL */
>>>
>>> It looks like the detection is broken?
>>
>> See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066
>
> Thanks for the pointer. Does the below fix it?
>
> Index: include/httpd.h
> ===================================================================
> --- include/httpd.h (revision 1898730)
> +++ include/httpd.h (working copy)
> @@ -2587,7 +2587,9 @@
> */
> #if defined(__cplusplus) && __cplusplus >= 201103L
> #define AP_THREAD_LOCAL thread_local
> -#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
> +#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 && \
> + (!defined(__GNUC__) || \
> + __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9))
> #define AP_THREAD_LOCAL _Thread_local
> #elif defined(__GNUC__) /* works for clang too */
> #define AP_THREAD_LOCAL __thread
>
>
> Regards
>
> Rüdiger

Looks good to me from inspection. I already tested a similar but not as
good patch. The next builds will pick up your one. Will report back in
an hour or so, whether it works for me.

Two additional things I already saw, but which are non.critical:

- configure flag --with-pcre no longer accepts an external pcre 8
installation directory. It seems in that case the flag must now point to
the path of the pcre-config script instead.

- configure for APR in the dependency tarball still fails for me due to
a bug in autoconf 2.71 used to create the configure script. That problem
was already reported by me during another release vote. I replaced the
changed three files in the bundled apr and apr-util with the earlier ones.

Thanks and regards,

Rainer

Am 08.03.2022 um 18:22 schrieb Rainer Jung:
> Am 08.03.2022 um 17:06 schrieb Ruediger Pluem:
>>
>>
>> On 3/8/22 4:38 PM, Rainer Jung wrote:
>>> Am 08.03.2022 um 16:33 schrieb Rainer Jung:
>>>>
>>>> Am 07.03.2022 um 16:55 schrieb Stefan Eissing:
>>>>> Hi all,
>>>>>
>>>>> Please find below the proposed release tarball and signatures:
>>>>>
>>>>> https://dist.apache.org/repos/dist/dev/httpd/
>>>>>
>>>>> I would like to call a VOTE over the next few days to release
>>>>> this candidate tarball httpd-2.4.53-rc1 as 2.4.53:
>>>>> [ ] +1: It's not just good, it's good enough!
>>>>> [ ] +0: Let's have a talk.
>>>>> [ ] -1: There's trouble in paradise. Here's what's wrong.
>>>>>
>>>>> The computed digests of the tarball up for vote are:
>>>>> sha256:
>>>>> 7559255a37adc5cb6f568ba224e435420f0a138cd9564162c9528b8ac08737b3
>>>>> *httpd-2.4.53-rc1.tar.gz
>>>>> sha512:
>>>>> a7734e2fa35389678be74bbc18136eef482ff9daecc2c1ed9c2c5eb410182735a94ff6ad248d0d4b6266e90161f2f8052d4871f381723c996ace0412b0219961
>>>>> *httpd-2.4.53-rc1.tar.gz
>>>>>
>>>>>
>>>>> The SVN candidate source is found at tags/2.4.53-rc1-candidate.
>>>>>
>>>>> Kind Regards,
>>>>> Stefan
>>>>
>>>> Not a vote yet, just an observation: on SLES12 (gcc 4.8.3, glibc
>>>> 2.19) and RHEL7 (gcc 4.8.2, glibc 2.19) with platform
>>>> compilers, configure detects it wants to set -std=gnu11. During make
>>>> I get a compilation error:
>>>>
>>>> server/util.c:3183:1: error: unknown type name ‘_Thread_local’
>>>>
>>>> The type "_Thread_local" comes from include/httpd.h:
>>>>
>>>>     2438  #if defined(__cplusplus) && __cplusplus >= 201103L
>>>>     2439  #define AP_THREAD_LOCAL thread_local
>>>>     2440  #elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
>>>>     2441  #define AP_THREAD_LOCAL _Thread_local
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>     2442  #elif defined(__GNUC__) /* works for clang too */
>>>>     2443  #define AP_THREAD_LOCAL __thread
>>>>     2444  #elif defined(WIN32) && defined(_MSC_VER)
>>>>     2445  #define AP_THREAD_LOCAL __declspec(thread)
>>>>     2446  #endif
>>>>     2447  #endif /* ndef AP_NO_THREAD_LOCAL */
>>>>
>>>> It looks like the detection is broken?
>>>
>>> See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203066
>>
>> Thanks for the pointer. Does the below fix it?
>>
>> Index: include/httpd.h
>> ===================================================================
>> --- include/httpd.h    (revision 1898730)
>> +++ include/httpd.h    (working copy)
>> @@ -2587,7 +2587,9 @@
>>    */
>>   #if defined(__cplusplus) && __cplusplus >= 201103L
>>   #define AP_THREAD_LOCAL thread_local
>> -#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112
>> +#elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112 && \
>> +      (!defined(__GNUC__) || \
>> +      __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9))
>>   #define AP_THREAD_LOCAL _Thread_local
>>   #elif defined(__GNUC__) /* works for clang too */
>>   #define AP_THREAD_LOCAL __thread
>>
>>
>> Regards
>>
>> Rüdiger
>
> Looks good to me from inspection. I already tested a similar but not as
> good patch. The next builds will pick up your one. Will report back in
> an hour or so, whether it works for me.
>
> Two additional things I already saw, but which are non.critical:
>
> - configure flag --with-pcre no longer accepts an external pcre 8
> installation directory. It seems in that case the flag must now point to
> the path of the pcre-config script instead.
>
> - configure for APR in the dependency tarball still fails for me due to
> a bug in autoconf 2.71 used to create the configure script. That problem
> was already reported by me during another release vote. I replaced the
> changed three files in the bundled apr and apr-util with the earlier ones.
>
> Thanks and regards,
>
> Rainer

You gcc 4.8 workaround for _Thread_local still looks good.

Solaris builds and all unit tests not yet done but compiles fine for all
my Linuxes.

Thanks!

Rainer

On 3/8/22 10:09 PM, Rainer Jung wrote:
>

>
> You gcc 4.8 workaround for _Thread_local still looks good.
>
> Solaris builds and all unit tests not yet done but compiles fine for all my Linuxes.
>
> Thanks!

Thanks for testing. I committed to trunk as r1898771 to throw it into our CI. If we need to tweak it further we can do later.

BTW: Once we have a final patch the same needs to be done for APR trunk and APR 1.8.x.

Regards

Rüdiger

On 3/8/22 10:09 PM, Rainer Jung wrote:
>

>>
>> Two additional things I already saw, but which are non.critical:
>>
>> - configure flag --with-pcre no longer accepts an external pcre 8 installation directory. It seems in that case the flag must
>> now point to the path of the pcre-config script instead.

Hmm. This could break existing configure calls. Probably not good for a patch release. Thanks for pointing out.

Regards

Rüdiger

CANCELLED.

Due to errors/warnings found during your tests, I cancel the vote on rc1.

Thanks for giving us these feedbacks! I'll put up the rc2 vote as soon
as we're ready.

Thanks,

Stefan


> Am 09.03.2022 um 08:50 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 3/8/22 10:09 PM, Rainer Jung wrote:
>>
>
>>>
>>> Two additional things I already saw, but which are non.critical:
>>>
>>> - configure flag --with-pcre no longer accepts an external pcre 8 installation directory. It seems in that case the flag must
>>> now point to the path of the pcre-config script instead.
>
> Hmm. This could break existing configure calls. Probably not good for a patch release. Thanks for pointing out.
>
> Regards
>
> Rüdiger
>

Am 09.03.2022 um 08:37 schrieb Ruediger Pluem:
>
>
> On 3/8/22 10:09 PM, Rainer Jung wrote:
>>
>
>>
>> You gcc 4.8 workaround for _Thread_local still looks good.
>>
>> Solaris builds and all unit tests not yet done but compiles fine for all my Linuxes.
>>
>> Thanks!
>
> Thanks for testing. I committed to trunk as r1898771 to throw it into our CI. If we need to tweak it further we can do later.
>
> BTW: Once we have a final patch the same needs to be done for APR trunk and APR 1.8.x.

Interesting: I did also compile APR trunk in my httpd release
preparations but didn't observe the failure. This probably was due to
the fact, that our APR trunk configure does not decide to add
-std=gnu11, so the test in the header file doesn't result in
_Thread_local being used.

Of course it still makes sense to apply the same patch (and also to
other APR branches containing the thread local code). Just wondering,
whether the different handling of the"std" compiler flag for httpd and
apr trunk is intentional.

Best regards,

Rainer

On 3/9/22 11:34 AM, Rainer Jung wrote:
> Am 09.03.2022 um 08:37 schrieb Ruediger Pluem:
>>
>>
>> On 3/8/22 10:09 PM, Rainer Jung wrote:
>>>
>>
>>>
>>> You gcc 4.8 workaround for _Thread_local still looks good.
>>>
>>> Solaris builds and all unit tests not yet done but compiles fine for all my Linuxes.
>>>
>>> Thanks!
>>
>> Thanks for testing. I committed to trunk as r1898771 to throw it into our CI. If we need to tweak it further we can do later.
>>
>> BTW: Once we have a final patch the same needs to be done for APR trunk and APR 1.8.x.
>
> Interesting: I did also compile APR trunk in my httpd release preparations but didn't observe the failure. This probably was due
> to the fact, that our APR trunk configure does not decide to add -std=gnu11, so the test in the header file doesn't result in
> _Thread_local being used.
>
> Of course it still makes sense to apply the same patch (and also to other APR branches containing the thread local code). Just
> wondering, whether the different handling of the"std" compiler flag for httpd and apr trunk is intentional.
>

Weird. I don't see -std=gnu11 added at all to my httpd build on RedHat 8.

gcc --version
gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4)
autoconf --version
autoconf (GNU Autoconf) 2.69

But I have tested the patch and get AP_THREAD_LOCAL set to _Thread_local as it should.

Regards

Rüdiger

Am 09.03.2022 um 13:58 schrieb Ruediger Pluem:
>
>
> On 3/9/22 11:34 AM, Rainer Jung wrote:
>> Am 09.03.2022 um 08:37 schrieb Ruediger Pluem:
>>>
>>>
>>> On 3/8/22 10:09 PM, Rainer Jung wrote:
>>>>
>>>
>>>>
>>>> You gcc 4.8 workaround for _Thread_local still looks good.
>>>>
>>>> Solaris builds and all unit tests not yet done but compiles fine for all my Linuxes.
>>>>
>>>> Thanks!
>>>
>>> Thanks for testing. I committed to trunk as r1898771 to throw it into our CI. If we need to tweak it further we can do later.
>>>
>>> BTW: Once we have a final patch the same needs to be done for APR trunk and APR 1.8.x.
>>
>> Interesting: I did also compile APR trunk in my httpd release preparations but didn't observe the failure. This probably was due
>> to the fact, that our APR trunk configure does not decide to add -std=gnu11, so the test in the header file doesn't result in
>> _Thread_local being used.
>>
>> Of course it still makes sense to apply the same patch (and also to other APR branches containing the thread local code). Just
>> wondering, whether the different handling of the"std" compiler flag for httpd and apr trunk is intentional.
>>
>
> Weird. I don't see -std=gnu11 added at all to my httpd build on RedHat 8.
>
> gcc --version
> gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4)
> autoconf --version
> autoconf (GNU Autoconf) 2.69
>
> But I have tested the patch and get AP_THREAD_LOCAL set to _Thread_local as it should.

Good. Concerning RHEL 8: I see the flag there neither due to:

RHEl7 :
checking for gcc -specs=/shared/build/autobuild/specs/specs.rhel7 option
to enable C11 features... -std=gnu11

RHEL 8:
checking for gcc -specs=/shared/build/autobuild/specs/specs.rhel8 option
to enable C11 features... none needed

The check for C11 was introduced in autoconf 2.70 as a new feature of
"AC_PROG_CC", which we have in configure.in for httpd and for APR.

The observed behavioral difference between httpd configure and (my) APR
trunk configure is due to the fact, that I generated my APR trunk
configure with autoconf 2.69, so the check does not run there. But it
would, once configure would be regenerated with modern autoconf. So
indeed the thread local detection fix should go in APR as well.

Thanks and regards,

Rainer

On Tue, Mar 8, 2022 at 6:22 PM Rainer Jung <rainer.jung@kippdata.de> wrote:
>
> - configure for APR in the dependency tarball still fails for me due to
> a bug in autoconf 2.71 used to create the configure script. That problem
> was already reported by me during another release vote. I replaced the
> changed three files in the bundled apr and apr-util with the earlier ones.

Does this depend on the RM's autoconf version?
If so, Stefan could you downgrade to autoconf 2.69 on your system? I
just did that on mine with:
$ apt install autoconf=2.69-1

Sorry, I don't have a better idea..

> Am 09.03.2022 um 14:25 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>
> On Tue, Mar 8, 2022 at 6:22 PM Rainer Jung <rainer.jung@kippdata.de> wrote:
>>
>> - configure for APR in the dependency tarball still fails for me due to
>> a bug in autoconf 2.71 used to create the configure script. That problem
>> was already reported by me during another release vote. I replaced the
>> changed three files in the bundled apr and apr-util with the earlier ones.
>
> Does this depend on the RM's autoconf version?
> If so, Stefan could you downgrade to autoconf 2.69 on your system? I
> just did that on mine with:
> $ apt install autoconf=2.69-1
>
> Sorry, I don't have a better idea..

I downgraded my autoconf from 2.71 to 2.69. Can I make some check before
or will we just see the outcome of the rc2? (which is easy to make)

- Stefan

Are we ready for an rc2 for 2.4.53?

> Am 09.03.2022 um 14:44 schrieb Stefan Eissing <stefan@eissing.org>:
>
>
>
>> Am 09.03.2022 um 14:25 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>>
>> On Tue, Mar 8, 2022 at 6:22 PM Rainer Jung <rainer.jung@kippdata.de> wrote:
>>>
>>> - configure for APR in the dependency tarball still fails for me due to
>>> a bug in autoconf 2.71 used to create the configure script. That problem
>>> was already reported by me during another release vote. I replaced the
>>> changed three files in the bundled apr and apr-util with the earlier ones.
>>
>> Does this depend on the RM's autoconf version?
>> If so, Stefan could you downgrade to autoconf 2.69 on your system? I
>> just did that on mine with:
>> $ apt install autoconf=2.69-1
>>
>> Sorry, I don't have a better idea..
>
> I downgraded my autoconf from 2.71 to 2.69. Can I make some check before
> or will we just see the outcome of the rc2? (which is easy to make)
>
> - Stefan

On Wed, Mar 9, 2022 at 2:45 PM Stefan Eissing <stefan@eissing.org> wrote:
>
> > Am 09.03.2022 um 14:25 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
> >
> > On Tue, Mar 8, 2022 at 6:22 PM Rainer Jung <rainer.jung@kippdata.de> wrote:
> >>
> >> - configure for APR in the dependency tarball still fails for me due to
> >> a bug in autoconf 2.71 used to create the configure script. That problem
> >> was already reported by me during another release vote. I replaced the
> >> changed three files in the bundled apr and apr-util with the earlier ones.
> >
> > Does this depend on the RM's autoconf version?
> > If so, Stefan could you downgrade to autoconf 2.69 on your system? I
> > just did that on mine with:
> > $ apt install autoconf=2.69-1
> >
> > Sorry, I don't have a better idea..
>
> I downgraded my autoconf from 2.71 to 2.69. Can I make some check before
> or will we just see the outcome of the rc2? (which is easy to make)

Thanks, I think a clean build on your local 2.4.x should do it:
$ cd 2.4.x
$ make distclean
$ rm `find . -name configure`
$ ./builconf
$ ./config.nice
$ make depend && make

or something like that.

On 3/9/22 2:46 PM, Stefan Eissing wrote:
> Are we ready for an rc2 for 2.4.53?

With r1898786 I would say yes.

Regards

Rüdiger

> Am 09.03.2022 um 15:05 schrieb Ruediger Pluem <rpluem@apache.org>:
>
>
>
> On 3/9/22 2:46 PM, Stefan Eissing wrote:
>> Are we ready for an rc2 for 2.4.53?
>
> With r1898786 I would say yes.

Thanks everyone, will do.

>
> Regards
>
> Rüdiger
>

> Am 09.03.2022 um 15:07 schrieb Stefan Eissing <stefan@eissing.org>:
>
>
>
>> Am 09.03.2022 um 15:05 schrieb Ruediger Pluem <rpluem@apache.org>:
>>
>>
>>
>> On 3/9/22 2:46 PM, Stefan Eissing wrote:
>>> Are we ready for an rc2 for 2.4.53?
>>
>> With r1898786 I would say yes.
>
> Thanks everyone, will do.

Everything prepped. Waiting for the green traffic light and then
will mail the new vote call.

- Stefan

> On Mar 9, 2022, at 8:58 AM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> On Wed, Mar 9, 2022 at 2:45 PM Stefan Eissing <stefan@eissing.org <mailto:stefan@eissing.org>> wrote:
>>
>>> Am 09.03.2022 um 14:25 schrieb Yann Ylavic <ylavic.dev@gmail.com>:
>>>
>>> On Tue, Mar 8, 2022 at 6:22 PM Rainer Jung <rainer.jung@kippdata.de> wrote:
>>>>
>>>> - configure for APR in the dependency tarball still fails for me due to
>>>> a bug in autoconf 2.71 used to create the configure script. That problem
>>>> was already reported by me during another release vote. I replaced the
>>>> changed three files in the bundled apr and apr-util with the earlier ones.
>>>
>>> Does this depend on the RM's autoconf version?
>>> If so, Stefan could you downgrade to autoconf 2.69 on your system? I
>>> just did that on mine with:
>>> $ apt install autoconf=2.69-1
>>>
>>> Sorry, I don't have a better idea..
>>
>> I downgraded my autoconf from 2.71 to 2.69. Can I make some check before
>> or will we just see the outcome of the rc2? (which is easy to make)
>
> Thanks, I think a clean build on your local 2.4.x should do it:
> $ cd 2.4.x
> $ make distclean
> $ rm `find . -name configure`
> $ ./builconf
> $ ./config.nice
> $ make depend && make
>

I've found make extraclean works a bit better