You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2019/02/27 23:06:26 UTC
Showstoppers to 1.7.0?
With several new features added to the 1.7 branch, the fixes to the
Netware locking we had deferred, and the proposed correction of
SIGUSR2, I'm wondering what we see as remaining obstacles.
I'd like to proceed with addressing the symlink vs. "other" reparse tag
questions raised for Windows, and will make the time to get the current
patch proposal and my type safety cleanups into trunk. PR 47630.
I'm also interested in fixing SFU issues of the Ubuntu on Windows
implementation with APR locking, and can dedicate a few hours
this weekend to look at where those errors stand.
Do we want to do something about de-prioritizing sysv semaphores
on linux by default with the 1.7.0 release?
Any other concerns ahead of 1.7.0?
Cheers,
Bill
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
I think we basically agreed to keep 0.9 at stasis. And expected
the next major prereq jump after 1.x at 2.0.
I'm not worried about maintaining support, but we should have
a serious dialog about going all Unicode/NT and ripping out all
of the Win 32-bit 9x code in the 2.0 trunk, and choosing a new
baseline at that point. I know some have built APR ANSI for
their own purposes, and it is a point we will have to ponder.
In the interim, the api function wrappers should allow us to keep
the ipv6 binding you mention as an optional function. That's the
course I'd prefer in the short-term, are you willing to hack that up
to keep the old stuff running? If no-one is willing then it really
has to be abandoned sooner.
On Tue, Mar 12, 2019 at 6:42 PM Gregg Smith <gl...@gknw.net> wrote:
> I finally got time to give this 1.7.0 a try and utterly failed :)
>
> r1839494 fixed a problem run into on VC when r1816608 added support for
> IPv6 link-local address scope/zone mapping. r1839494 requires NT6.
>
> Our apr.hw is still targeting NT5 which has been EOL for eons now, 6.0
> also as Vista and Server 2008 went EOL years ago. 6.1 goes EOL next year
> but what does everyone think about changing that default in apr.hw from
> 0x0501 to 0x0601 or 0x0600 at minimum?
>
> I do not remember if a PMC vote was required when we went from 400 to
> 500 to 501.
>
> Cheers,
>
> Gregg
>
>
>
> On 2/27/2019 3:06 PM, William A Rowe Jr wrote:
> > With several new features added to the 1.7 branch, the fixes to the
> > Netware locking we had deferred, and the proposed correction of
> > SIGUSR2, I'm wondering what we see as remaining obstacles.
> >
> > I'd like to proceed with addressing the symlink vs. "other" reparse tag
> > questions raised for Windows, and will make the time to get the current
> > patch proposal and my type safety cleanups into trunk. PR 47630.
> >
> > I'm also interested in fixing SFU issues of the Ubuntu on Windows
> > implementation with APR locking, and can dedicate a few hours
> > this weekend to look at where those errors stand.
> >
> > Do we want to do something about de-prioritizing sysv semaphores
> > on linux by default with the 1.7.0 release?
> >
> > Any other concerns ahead of 1.7.0?
> >
> > Cheers,
> >
> > Bill
> >
>
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Hi Greg,
On Tue, Mar 12, 2019 at 6:42 PM Gregg Smith <gl...@gknw.net> wrote:
> I finally got time to give this 1.7.0 a try and utterly failed :)
>
> r1839494 fixed a problem run into on VC when r1816608 added support for
> IPv6 link-local address scope/zone mapping. r1839494 requires NT6.
>
> Our apr.hw is still targeting NT5 which has been EOL for eons now, 6.0
> also as Vista and Server 2008 went EOL years ago. 6.1 goes EOL next year
> but what does everyone think about changing that default in apr.hw from
> 0x0501 to 0x0601 or 0x0600 at minimum?
>
As with all the more modern functions, APR_DECLARE_LATE_DLL_FUNC
is useful here. Because NT isn't IPV6, this code won't be triggered on any
OS that old.
Give apr 1.7.0 another spin after r1855857 and let us know how it goes.
Re: Showstoppers to 1.7.0?
Posted by Gregg Smith <gl...@gknw.net>.
I finally got time to give this 1.7.0 a try and utterly failed :)
r1839494 fixed a problem run into on VC when r1816608 added support for
IPv6 link-local address scope/zone mapping. r1839494 requires NT6.
Our apr.hw is still targeting NT5 which has been EOL for eons now, 6.0
also as Vista and Server 2008 went EOL years ago. 6.1 goes EOL next year
but what does everyone think about changing that default in apr.hw from
0x0501 to 0x0601 or 0x0600 at minimum?
I do not remember if a PMC vote was required when we went from 400 to
500 to 501.
Cheers,
Gregg
On 2/27/2019 3:06 PM, William A Rowe Jr wrote:
> With several new features added to the 1.7 branch, the fixes to the
> Netware locking we had deferred, and the proposed correction of
> SIGUSR2, I'm wondering what we see as remaining obstacles.
>
> I'd like to proceed with addressing the symlink vs. "other" reparse tag
> questions raised for Windows, and will make the time to get the current
> patch proposal and my type safety cleanups into trunk. PR 47630.
>
> I'm also interested in fixing SFU issues of the Ubuntu on Windows
> implementation with APR locking, and can dedicate a few hours
> this weekend to look at where those errors stand.
>
> Do we want to do something about de-prioritizing sysv semaphores
> on linux by default with the 1.7.0 release?
>
> Any other concerns ahead of 1.7.0?
>
> Cheers,
>
> Bill
>
Re: Showstoppers to 1.7.0?
Posted by Branko Čibej <br...@apache.org>.
On 25.03.2019 07:17, Gregg Smith wrote:
> Hi Yann,
>
> No, r1856096 doesn't help, but thanks.
>
> I think VS just doesn't like these arrays of unknown size.
>
> usrc = (unsigned char[]){ };
> utarget = (unsigned char[]){ };
This is not ANSI C. Visual Studio doesn't support C99 and later extensions.
-- Brane
> It's fine with the ones that are initialized with values like
>
> usrc = (unsigned char[]){'f'};
> utarget = (unsigned char[]){'f', 'o', 'o'};
>
>
>
> On 3/22/2019 4:42 PM, Yann Ylavic wrote:
>> On Fri, Mar 22, 2019 at 6:37 PM Gregg Smith <gl...@gknw.net> wrote:
>>>
>>> testencode doesn't want to compile on Visual Studio.
>>> A showstopper maybe not but it is nice to run the tests to compare with
>>> previous versions.
>>>
>>> abts.c
>>> testencode.c
>>> testencode.c(91): error C2059: syntax error: '}'
>>> testencode.c(206): error C2059: syntax error: '}'
>>> testencode.c(416): error C2059: syntax error: '}'
>>> testencode.c(747): error C2059: syntax error: '}'
>>> testskiplist.c
>>
>> Thanks Gregg, does r1856096 work?
>>
Re: Showstoppers to 1.7.0?
Posted by Gregg Smith <gl...@gknw.net>.
My working copy just refuses to show the changes but the merge info is
there, strange. Taking testencode.c from trunk and it builds great. Test
passes. Thank you.
cheers
On 3/25/2019 4:05 AM, Yann Ylavic wrote:
> Hi Gregg,
>
> On Mon, Mar 25, 2019 at 6:17 AM Gregg Smith <gl...@gknw.net> wrote:
>>
>> No, r1856096 doesn't help, but thanks.
>
> I missed most of the cases actually, better with r1856178?
>
Re: Showstoppers to 1.7.0?
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Gregg,
On Mon, Mar 25, 2019 at 6:17 AM Gregg Smith <gl...@gknw.net> wrote:
>
> No, r1856096 doesn't help, but thanks.
I missed most of the cases actually, better with r1856178?
Re: Showstoppers to 1.7.0?
Posted by Gregg Smith <gl...@gknw.net>.
Hi Yann,
No, r1856096 doesn't help, but thanks.
I think VS just doesn't like these arrays of unknown size.
usrc = (unsigned char[]){ };
utarget = (unsigned char[]){ };
It's fine with the ones that are initialized with values like
usrc = (unsigned char[]){'f'};
utarget = (unsigned char[]){'f', 'o', 'o'};
On 3/22/2019 4:42 PM, Yann Ylavic wrote:
> On Fri, Mar 22, 2019 at 6:37 PM Gregg Smith <gl...@gknw.net> wrote:
>>
>> testencode doesn't want to compile on Visual Studio.
>> A showstopper maybe not but it is nice to run the tests to compare with
>> previous versions.
>>
>> abts.c
>> testencode.c
>> testencode.c(91): error C2059: syntax error: '}'
>> testencode.c(206): error C2059: syntax error: '}'
>> testencode.c(416): error C2059: syntax error: '}'
>> testencode.c(747): error C2059: syntax error: '}'
>> testskiplist.c
>
> Thanks Gregg, does r1856096 work?
>
Re: Showstoppers to 1.7.0?
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Mar 22, 2019 at 6:37 PM Gregg Smith <gl...@gknw.net> wrote:
>
> testencode doesn't want to compile on Visual Studio.
> A showstopper maybe not but it is nice to run the tests to compare with
> previous versions.
>
> abts.c
> testencode.c
> testencode.c(91): error C2059: syntax error: '}'
> testencode.c(206): error C2059: syntax error: '}'
> testencode.c(416): error C2059: syntax error: '}'
> testencode.c(747): error C2059: syntax error: '}'
> testskiplist.c
Thanks Gregg, does r1856096 work?
Re: Showstoppers to 1.7.0?
Posted by Gregg Smith <gl...@gknw.net>.
testencode doesn't want to compile on Visual Studio.
A showstopper maybe not but it is nice to run the tests to compare with
previous versions.
abts.c
testencode.c
testencode.c(91): error C2059: syntax error: '}'
testencode.c(206): error C2059: syntax error: '}'
testencode.c(416): error C2059: syntax error: '}'
testencode.c(747): error C2059: syntax error: '}'
testskiplist.c
On 3/1/2019 10:04 AM, William A Rowe Jr wrote:
>
> My question was entirely limited to apr, I hadn't yet considered pushing
> for an apr-util release. The concerns you and Graham are discussing,
> Nick's interest in libxml2 and my interest in simplifying win32+iconv
> without GPL libiconv all fall into the later.
>
> Perhaps resolving apr 1.7 this month (what I've raised), plus targeting
> about a month from now to move forward with apr-util 1.7 would be
> helpful to nudge some of these efforts along?
>
Re: Showstoppers to 1.7.0?
Posted by Nick Kew <ni...@apache.org>.
On Fri, 1 Mar 2019 12:04:34 -0600
William A Rowe Jr <wr...@rowe-clan.net> wrote:
> My question was entirely limited to apr, I hadn't yet considered
> pushing for an apr-util release.
Hehe. It occurred to me to ask that, but only after
my reply yesterday night. :)
> Perhaps resolving apr 1.7 this month (what I've raised), plus
> targeting about a month from now to move forward with apr-util 1.7
> would be helpful to nudge some of these efforts along?
Indeed - thanks for taking the initiative (again)!
A bugzilla trawl would be good. I'll see if I can find
a round tuit down the back of the sofa.
--
Nick Kew
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Mar 1, 2019 at 5:01 AM Yann Ylavic <yl...@gmail.com> wrote:
> On Thu, Feb 28, 2019 at 12:06 AM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > Any other concerns ahead of 1.7.0?
>
> There are some backports I need to revert, the dynamic linking (as
> opposed to dynamic loading) of apr_crypto libraries -1'ed by Graham
> (see discussion in r1833359 and r1833421 threads), and thus the new
> PRNG stuff depending on a single library init/deinit point in APR and
> (hopefully) as much direct as possible calls to the underlying crypto
> lib primitives (i.e. no insane indirections).
>
My question was entirely limited to apr, I hadn't yet considered pushing
for an apr-util release. The concerns you and Graham are discussing,
Nick's interest in libxml2 and my interest in simplifying win32+iconv
without GPL libiconv all fall into the later.
Perhaps resolving apr 1.7 this month (what I've raised), plus targeting
about a month from now to move forward with apr-util 1.7 would be
helpful to nudge some of these efforts along?
Re: Showstoppers to 1.7.0?
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Feb 28, 2019 at 12:06 AM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Any other concerns ahead of 1.7.0?
There are some backports I need to revert, the dynamic linking (as
opposed to dynamic loading) of apr_crypto libraries -1'ed by Graham
(see discussion in r1833359 and r1833421 threads), and thus the new
PRNG stuff depending on a single library init/deinit point in APR and
(hopefully) as much direct as possible calls to the underlying crypto
lib primitives (i.e. no insane indirections).
Even if I find that DSOs in crypto code complicate a lot of things
(which usually goes against cryptography), I tried to work on keeping
them and being able to load/unload/reload at wish, but got blocked at
some point with openssl refusing to reload. I gave up due to lack of
time (status: WIP in my tree).
In short more work and fighting against the libs vs dynamic loader is
needed (on a lib/version case by case basis), no very exciting..
So I'll revert these in 1.7, but I feel a bit sour about the status
quo because currently one can't use APR and some other stuff with the
same crypto library; who is responsible for the init/deinit? (e.g.
mod_ssl vs mod_crypto, not to talk about potential APR's PRNG at the
httpd/core level...)
We have this mess today, APR looks like a central place to
init/deinit, and blocking progress because it's not how "drivers"
should work and so on is not helpful (who wants to load multiple
crypto libs? and even though why dynamic linking wouldn't work?). We
need simple/working/efficient things, not fights against the libs, and
we'd better put energy in new/nowadays/unbroken crypto algorithms
interfaces..
Sorry for the (little) rant,
Yann.
Re: Showstoppers to 1.7.0?
Posted by Nick Kew <ni...@apache.org>.
> On 27 Feb 2019, at 23:06, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> With several new features added to the 1.7 branch, the fixes to the
> Netware locking we had deferred, and the proposed correction of
> SIGUSR2, I'm wondering what we see as remaining obstacles.
Did I backport the xml build option for libxml2? If not, that's a round
tuit I need to get before 1.7. Will take a look tomorrow.
--
Nick Kew
Re: Showstoppers to 1.7.0?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Mar 14, 2019, at 9:06 AM, Stefan Sperling <st...@stsp.name> wrote:
>
> On Thu, Mar 14, 2019 at 07:49:41AM -0400, Jim Jagielski wrote:
>> I use maintainer-mode all the time... as I said, building httpd does not cause any errors due to APR_SSIZE_T_FMT
>
> Ah, sorry Jim. I misread your message.
No worries... it seems like the issue is just for OpenBSD as I understand it. I do see one report of someone who had an issue with it on macOS, but that install seems broken (DARWIN_10 isn't even defined!) rather than an issue w/ APR proper.
Re: Showstoppers to 1.7.0?
Posted by Stefan Sperling <st...@stsp.name>.
On Thu, Mar 14, 2019 at 07:49:41AM -0400, Jim Jagielski wrote:
> I use maintainer-mode all the time... as I said, building httpd does not cause any errors due to APR_SSIZE_T_FMT
Ah, sorry Jim. I misread your message.
Re: Showstoppers to 1.7.0?
Posted by Jim Jagielski <ji...@jaguNET.com>.
I use maintainer-mode all the time... as I said, building httpd does not cause any errors due to APR_SSIZE_T_FMT
> On Mar 14, 2019, at 2:16 AM, Stefan Sperling <st...@stsp.name> wrote:
>
> On Wed, Mar 13, 2019 at 04:22:46PM -0400, Jim Jagielski wrote:
>> Just a FYI that compiling httpd trunk (HEAD) against apr-1.7 (HEAD) and apu-1.6 (HEAD), I get no error messages about APR_OFF_T_FMT issues, so I'm not exactly sure where these are coming from for macOS
>>
>> % uname -a
>> Darwin jimsys.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64
>> % clang -v
>> Apple LLVM version 10.0.0 (clang-1000.11.45.5)
>> Target: x86_64-apple-darwin18.2.0
>> Thread model: posix
>> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> Build errors show up in httpd, not APR, and they only show up if
> --enable-maintainer-mode is passed to httpd's configure script
> because the httpd build will then use: -Wformat -Werror
>
> I don't have first-hand evidence from Mac OS but this is how the
> problem materializes on OpenBSD.
Re: Showstoppers to 1.7.0?
Posted by Stefan Sperling <st...@stsp.name>.
On Wed, Mar 13, 2019 at 04:22:46PM -0400, Jim Jagielski wrote:
> Just a FYI that compiling httpd trunk (HEAD) against apr-1.7 (HEAD) and apu-1.6 (HEAD), I get no error messages about APR_OFF_T_FMT issues, so I'm not exactly sure where these are coming from for macOS
>
> % uname -a
> Darwin jimsys.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64
> % clang -v
> Apple LLVM version 10.0.0 (clang-1000.11.45.5)
> Target: x86_64-apple-darwin18.2.0
> Thread model: posix
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Build errors show up in httpd, not APR, and they only show up if
--enable-maintainer-mode is passed to httpd's configure script
because the httpd build will then use: -Wformat -Werror
I don't have first-hand evidence from Mac OS but this is how the
problem materializes on OpenBSD.
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Mar 14, 2019 at 3:02 PM Yann Ylavic <yl...@gmail.com> wrote:
> On Thu, Mar 14, 2019 at 8:38 PM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic <yl...@gmail.com>
> wrote:
> >>
> >> Possibly to resolve APR_<INTTYPE>_T_FMT on system with
> >> [std]int[types].h, we could bind to the standard (C99?) format
> >> PR[dxo..]N, especially since we configure the format based off
> >> $ac_cv_sizeof_<inttype>, so something like:
> >> #define APR_<INTTYPE>_T_FMT PR[dxo..]`expr $ac_cv_sizeof_<inttype>_t *
> 8`
> >>
> >> That should work on most "modern" systems/compilers (including
> >> -stdc=c89), no? And for older ones the current as fallback could be
> >> reasonable.
> >
> >
> > No, not with c89 (not as any sort of standard, -stdc is irrelevant.)
>
> Do you mean C89 only compilers which don't support C99+ (i.e. -stdc or
> alike), and thus no inttypes.h and so on?
> Well, configure would work as today for them, and AIUI this is not on
> those systems that we have an issue.
>
The inttypes.h itself doesn't tell us the defines exist, for earlier drafts
and
precursors to C99.
What I mean is, adding more lines to configure.in is the last thing we want
to do, introducing extra complexity. We know what we have to do, determine
the actual int type correspondence and use the corresponding formatter.
In some strange cases we seem to pick up an environment where two types
are effectively equivilant but the %[[l]l]d formatters won't align because
they
are future-proofing the possibility of two now-equivalent int types from
being
distinct later on.
This suggestion above simply introduces the complexity of worrying about
the bitsize. We gain nothing choosing PRIld64 when we can simply use %d.
(For those unfamiliar, PRI is *upper case* prefix of a lowercase type, and
not the prefix 'PR' with type 'ld' - adding to legibility concerns.)
No, I'm not in favor of adding fixed int width considerations and congesting
some already horrible code even further, and let's not double our efforts
to decipher bytewidth and bitwidth of all these types. My current draft
should
be more portable provided that APR_TRY_COMPILE_NO_WARNING catches
and kills the code emitting warnings about printf format mismatches, and we
can trash a bunch of special cases in apr trunk.
dnl
dnl APR_CHECK_TYPES_COMPATIBLE(TYPE-1, TYPE-2, FMT-TAG,
dnl [ACTION-IF-TRUE], [ACTION-IF-FALSE])
dnl
dnl Try to determine whether two types are the same and accept the given
dnl printf formatter (bare token, e.g. literal d, ld, etc).
dnl
AC_DEFUN([APR_CHECK_TYPES_FMT_COMPATIBLE], [
define([apr_cvname], apr_cv_typematch_[]translit([$1], [ ],
[_])_[]translit([$2], [ ], [_])_[][$3])
AC_CACHE_CHECK([whether $1 and $2 use fmt %$3], apr_cvname, [
APR_TRY_COMPILE_NO_WARNING([#include <sys/types.h>
#include <stdio.h>], [
$1 chk1, *ptr1;
$2 chk2, *ptr2 = &chk1;
ptr1 = &chk2;
*ptr1 = *ptr2 = 0;
printf("%$3 %$3", chk1, chk2);
], [apr_cvname=yes
$4], [apr_cvname=no
$5])])
])
Re: Showstoppers to 1.7.0?
Posted by Jim Jagielski <ji...@jaguNET.com>.
Yep, all good. Thx!
> On Mar 19, 2019, at 3:12 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Tue, Mar 19, 2019 at 1:51 PM Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
> Under OSX/macOS, whether off_t and/or size_t are long long or long
> depends on compile time and the actual platform being compiled for.
> To have a universal *.h file, you need those checks for __LP64__
> that are determined during the build of whatever is *using* APR,
> and not so much during when APR itself is built. If I adjust to
> bypass all Darwin specifics and allow the fall-through, it actually
> *creates* a defect on macOS depending on which version we
> are building on and which version of Xcode being used.
>
> But not for the specific flavor that is built at that moment, one hopes!
>
> As it is, right now, with the __APPLE__ macro fix I added to
> apr-*, all is good from OSX 10.7 (the oldest I have) thru 10.14
> using both official Apple Xcode cc/clang and MacPorts gcc.
>
> Excellent news, thanks for confirming that the fix for BSD didn't disrupt
> OSX! I'd still love to have someone spotting on AIX, Solaris etc to
> ensure those even more odd architecture compilers (non-gcc) aren't
> disrupted by the new ./configure logic.
>
>
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Mar 19, 2019 at 1:51 PM Jim Jagielski <ji...@jagunet.com> wrote:
> Under OSX/macOS, whether off_t and/or size_t are long long or long
> depends on compile time and the actual platform being compiled for.
> To have a universal *.h file, you need those checks for __LP64__
> that are determined during the build of whatever is *using* APR,
> and not so much during when APR itself is built. If I adjust to
> bypass all Darwin specifics and allow the fall-through, it actually
> *creates* a defect on macOS depending on which version we
> are building on and which version of Xcode being used.
>
But not for the specific flavor that is built at that moment, one hopes!
> As it is, right now, with the __APPLE__ macro fix I added to
> apr-*, all is good from OSX 10.7 (the oldest I have) thru 10.14
> using both official Apple Xcode cc/clang and MacPorts gcc.
>
Excellent news, thanks for confirming that the fix for BSD didn't disrupt
OSX! I'd still love to have someone spotting on AIX, Solaris etc to
ensure those even more odd architecture compilers (non-gcc) aren't
disrupted by the new ./configure logic.
Re: Showstoppers to 1.7.0?
Posted by Jim Jagielski <ji...@jaguNET.com>.
Under OSX/macOS, whether off_t and/or size_t are long long or long
depends on compile time and the actual platform being compiled for.
To have a universal *.h file, you need those checks for __LP64__
that are determined during the build of whatever is *using* APR,
and not so much during when APR itself is built. If I adjust to
bypass all Darwin specifics and allow the fall-through, it actually
*creates* a defect on macOS depending on which version we
are building on and which version of Xcode being used.
As it is, right now, with the __APPLE__ macro fix I added to
apr-*, all is good from OSX 10.7 (the oldest I have) thru 10.14
using both official Apple Xcode cc/clang and MacPorts gcc.
> On Mar 19, 2019, at 2:30 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Tue, Mar 19, 2019 at 12:58 PM Jim Jagielski <jim@jagunet.com <ma...@jagunet.com>> wrote:
>
> Hi Bill, can you let me know what issues you saw? Last I checked, the
> Darwin stuff in configure.in <http://configure.in/> and apr.h.in <http://apr.h.in/> hasn't been touched, nor an issue,
> in ages, except for the recent DARWIN pre-defined cpp macro hiccup.
>
> Hi Jim - see stsp's many posts over the months r.e. BSD. It had the same
> observed issue, and your patch obviously was no help, because BSD is
> not -D APPLE.
>
> With the corrections tested by Stefan now, BSD will fall through to using
> the %lld pattern. Actually, it fixes the observed defect on OSX too, even
> with the APPLE patch omitted, but we needed to correct all the details
> covered with your fix specific to OSX, not just the one %ld quirk.
>
> Sure, the Darwin stuff has some weirdness, but that was closed
> long ago and was/is due to APR being, after all, a library, and must
> be portable to all platforms that OSX/macOS are being built for despite
> how the library itself was built. Even some of Apple's own *.h files
> include these work-arounds. If we're doing something wrong, let's
> fix it. Thx!
>
> We definitely want to clean things up, but I'd consider it unwise to
> make very many changes in apr 1.x. Lots of edge cases can probably
> be dropped by getting the tests right in the first place in autoconf, but
> let's save most of that for APR 2?
>
> The new patches are for BSD and every architecture other than OSX
> that grows quirky about %ld vs %lld where long and long long are
> presently the same byte width, nothing to do with the better APPLE
> determination you caught last week.
>
> Stefan indicates there is a lingering problem with APR_INT64_T_FMT
> which is bizarre because why would we ever pair long with %lld or
> long long with %ld? But we did, and I'm looking for that defect still.
>
>
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Mar 19, 2019 at 12:58 PM Jim Jagielski <ji...@jagunet.com> wrote:
>
> Hi Bill, can you let me know what issues you saw? Last I checked, the
> Darwin stuff in configure.in and apr.h.in hasn't been touched, nor an
> issue,
> in ages, except for the recent DARWIN pre-defined cpp macro hiccup.
>
Hi Jim - see stsp's many posts over the months r.e. BSD. It had the same
observed issue, and your patch obviously was no help, because BSD is
not -D APPLE.
With the corrections tested by Stefan now, BSD will fall through to using
the %lld pattern. Actually, it fixes the observed defect on OSX too, even
with the APPLE patch omitted, but we needed to correct all the details
covered with your fix specific to OSX, not just the one %ld quirk.
> Sure, the Darwin stuff has some weirdness, but that was closed
> long ago and was/is due to APR being, after all, a library, and must
> be portable to all platforms that OSX/macOS are being built for despite
> how the library itself was built. Even some of Apple's own *.h files
> include these work-arounds. If we're doing something wrong, let's
> fix it. Thx!
>
We definitely want to clean things up, but I'd consider it unwise to
make very many changes in apr 1.x. Lots of edge cases can probably
be dropped by getting the tests right in the first place in autoconf, but
let's save most of that for APR 2?
The new patches are for BSD and every architecture other than OSX
that grows quirky about %ld vs %lld where long and long long are
presently the same byte width, nothing to do with the better APPLE
determination you caught last week.
Stefan indicates there is a lingering problem with APR_INT64_T_FMT
which is bizarre because why would we ever pair long with %lld or
long long with %ld? But we did, and I'm looking for that defect still.
Re: Showstoppers to 1.7.0?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Mar 14, 2019, at 6:00 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
>
> No, I mean, if you want to fall down that rabbit hole, be my guest, and I'll check
> out as a maintainer of our autocrap. Already sporting a killer headache of
> days in and out of the mechanics of WTF we have done to ourselves across
> configure.in <http://configure.in/> and apr.h.in <http://apr.h.in/> on Darwin in particular, w.r.t. both all the groups of
> LFS, apr_size_t and apr_off_t exceptions, glued together in different manners.
>
Hi Bill, can you let me know what issues you saw? Last I checked, the
Darwin stuff in configure.in and apr.h.in hasn't been touched, nor an issue,
in ages, except for the recent DARWIN pre-defined cpp macro hiccup.
Sure, the Darwin stuff has some weirdness, but that was closed
long ago and was/is due to APR being, after all, a library, and must
be portable to all platforms that OSX/macOS are being built for despite
how the library itself was built. Even some of Apple's own *.h files
include these work-arounds. If we're doing something wrong, let's
fix it. Thx!
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Mar 14, 2019 at 3:02 PM Yann Ylavic <yl...@gmail.com> wrote:
> On Thu, Mar 14, 2019 at 8:38 PM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic <yl...@gmail.com>
> wrote:
> >>
> >> Possibly to resolve APR_<INTTYPE>_T_FMT on system with
> >> [std]int[types].h, we could bind to the standard (C99?) format
> >> PR[dxo..]N, especially since we configure the format based off
> >> $ac_cv_sizeof_<inttype>, so something like:
> >> #define APR_<INTTYPE>_T_FMT PR[dxo..]`expr $ac_cv_sizeof_<inttype>_t *
> 8`
> >>
> >> That should work on most "modern" systems/compilers (including
> >> -stdc=c89), no? And for older ones the current as fallback could be
> >> reasonable.
> >
> > No, not with c89 (not as any sort of standard, -stdc is irrelevant.)
>
> Do you mean C89 only compilers which don't support C99+ (i.e. -stdc or
> alike), and thus no inttypes.h and so on?
>
No, I mean, if you want to fall down that rabbit hole, be my guest, and
I'll check
out as a maintainer of our autocrap. Already sporting a killer headache of
days in and out of the mechanics of WTF we have done to ourselves across
configure.in and apr.h.in on Darwin in particular, w.r.t. both all the
groups of
LFS, apr_size_t and apr_off_t exceptions, glued together in different
manners.
Here's some encouragement towards your effort;
http://clang-developers.42468.n3.nabble.com/libcxx-Platform-independent-printing-using-format-constants-td4027284.html
Well, configure would work as today for them, and AIUI this is not on
> those systems that we have an issue.
>
Right, so we leave the existing exception logic, bolting on more exception
logic that may or may not trigger correctly depending on defines passed
before including apr.h during ./configure vs. the user's project tooling.
Sounds like a brilliant idea :)
Re: Showstoppers to 1.7.0?
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Mar 14, 2019 at 8:38 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic <yl...@gmail.com> wrote:
>>
>> Possibly to resolve APR_<INTTYPE>_T_FMT on system with
>> [std]int[types].h, we could bind to the standard (C99?) format
>> PR[dxo..]N, especially since we configure the format based off
>> $ac_cv_sizeof_<inttype>, so something like:
>> #define APR_<INTTYPE>_T_FMT PR[dxo..]`expr $ac_cv_sizeof_<inttype>_t * 8`
>>
>> That should work on most "modern" systems/compilers (including
>> -stdc=c89), no? And for older ones the current as fallback could be
>> reasonable.
>
>
> No, not with c89 (not as any sort of standard, -stdc is irrelevant.)
Do you mean C89 only compilers which don't support C99+ (i.e. -stdc or
alike), and thus no inttypes.h and so on?
Well, configure would work as today for them, and AIUI this is not on
those systems that we have an issue.
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic <yl...@gmail.com> wrote:
> Possibly to resolve APR_<INTTYPE>_T_FMT on system with
> [std]int[types].h, we could bind to the standard (C99?) format
> PR[dxo..]N, especially since we configure the format based off
> $ac_cv_sizeof_<inttype>, so something like:
> #define APR_<INTTYPE>_T_FMT PR[dxo..]`expr $ac_cv_sizeof_<inttype>_t * 8`
>
> That should work on most "modern" systems/compilers (including
> -stdc=c89), no? And for older ones the current as fallback could be
> reasonable.
>
No, not with c89 (not as any sort of standard, -stdc is irrelevant.)
So we are back to adding complexity, not simplifying the question.
Re: Showstoppers to 1.7.0?
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Mar 13, 2019 at 9:33 PM Jim Jagielski <ji...@jagunet.com> wrote:
>
> Just a FYI that compiling httpd trunk (HEAD) against apr-1.7 (HEAD) and apu-1.6 (HEAD), I get no error messages about APR_OFF_T_FMT issues, so I'm not exactly sure where these are coming from for macOS
Possibly to resolve APR_<INTTYPE>_T_FMT on system with
[std]int[types].h, we could bind to the standard (C99?) format
PR[dxo..]N, especially since we configure the format based off
$ac_cv_sizeof_<inttype>, so something like:
#define APR_<INTTYPE>_T_FMT PR[dxo..]`expr $ac_cv_sizeof_<inttype>_t * 8`
That should work on most "modern" systems/compilers (including
-stdc=c89), no? And for older ones the current as fallback could be
reasonable..
The attached patch is a first try with off_t (not "technically" an
inttype but same kind), could be generalized to inttypes ([s]size_t,
ptrdiff_t, ..) if it suvives some tests on systems we support/can;
seems to work on my linux(es) building httpd --maintainer-mode
--with-included-apr at least.
E.g. in my generated apr.h: #define APR_OFF_T_FMT PRId64
Can of worms?
Re: Showstoppers to 1.7.0?
Posted by Jim Jagielski <ji...@jaguNET.com>.
Just a FYI that compiling httpd trunk (HEAD) against apr-1.7 (HEAD) and apu-1.6 (HEAD), I get no error messages about APR_OFF_T_FMT issues, so I'm not exactly sure where these are coming from for macOS
% uname -a
Darwin jimsys.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64
% clang -v
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Re: Showstoppers to 1.7.0?
Posted by Stefan Sperling <st...@stsp.name>.
On Tue, Mar 12, 2019 at 02:21:46PM -0500, William A Rowe Jr wrote:
> Rereading the APR_CHECK_TYPES_COMPATIBLE logic, I misread it. We test and
> successively pass ssize_t as int compatible, followed by retesting and
> passing ssize_t as long compatible, so the resulting
> APR_SSIZE_T_FMT pattern is "ld". However, even that test is wonky as it
> relies on a gcc/icc internal nonstandard __builtin_types_compatible_p call.
>
> Try compile is our friend here, working on the more general fix to test
> that sizeof type $1 is sizeof type $2 and that the corresponding "d" "ld"
> "lld" param works in a strict printf.
Nice! Please CC me when you have a patch and I will test it on OpenBSD.
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Mar 12, 2019 at 1:59 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:
>
> One obvious flaw I had missed in my earlier list, the problem with
> maintainer mode strictness and our APR_OFF_T_FMT warnings.
>
> I think the patch is as simple as prioritizing int over long... which
> would be the same logic already in use for size_t etc. Could those on
> affected platforms including the latest osx have a go at this configure
> hack before I commit it? (Remember to ./buildconf after patching).
>
> If this doesn't consistently work, I believe we would want to create a
> flavor of the APR_CHECK_TYPES_COMPATIBLE() macro to verify type and format
> pattern against an actual strict printf() invocation.
>
Scratch that... it won't solve osx. sf and wuzhouhui already identified the
exact darwin error;
a.c:7:33: warning: format specifies type 'long' but the argument has type
'apr_off_t' (aka 'long long') [-Wformat]
printf("%" APR_OFF_T_FMT "\n", a);
Rereading the APR_CHECK_TYPES_COMPATIBLE logic, I misread it. We test and
successively pass ssize_t as int compatible, followed by retesting and
passing ssize_t as long compatible, so the resulting
APR_SSIZE_T_FMT pattern is "ld". However, even that test is wonky as it
relies on a gcc/icc internal nonstandard __builtin_types_compatible_p call.
Try compile is our friend here, working on the more general fix to test
that sizeof type $1 is sizeof type $2 and that the corresponding "d" "ld"
"lld" param works in a strict printf.
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Mar 8, 2019 at 2:19 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:
>
> I'd like to give this question a few more days, and finally lock down
> our 1.7.0 candidate sometime later next week.
>
One obvious flaw I had missed in my earlier list, the problem with
maintainer mode strictness and our APR_OFF_T_FMT warnings.
I think the patch is as simple as prioritizing int over long... which would
be the same logic already in use for size_t etc. Could those on affected
platforms including the latest osx have a go at this configure hack before
I commit it? (Remember to ./buildconf after patching).
If this doesn't consistently work, I believe we would want to create a
flavor of the APR_CHECK_TYPES_COMPATIBLE() macro to verify type and format
pattern against an actual strict printf() invocation.
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Mar 13, 2019 at 6:53 AM Yann Ylavic <yl...@gmail.com> wrote:
> On Wed, Mar 13, 2019 at 11:47 AM Yann Ylavic <yl...@gmail.com> wrote:
> >
> > On Fri, Mar 8, 2019 at 9:19 PM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> > >
> > > On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> > >>
> > >> Do we want to do something about de-prioritizing sysv semaphores
> > >> on linux by default with the 1.7.0 release?
> > >
> > > Comments? I know some distributors already hack around our default
> > > autoconf locking mechanism choice on modern Linux.
> >
> > I'm +1 on this one, proc-pthread should be the default on linux (and
> > possibly solaris too if not already the case).
>
> Actually on all systems with both pthread_mutexattr_setpshared() and
> pthread_mutexattr_setrobust[_np]().
> ISTM that on some systems there is pthread_mutexattr_setrobust() w/o
> the _np suffix (like *BSD), so we might want to check it for
> HAVE_PTHREAD_MUTEX_ROBUST in apr_threads.m4 too..
>
Is anyone prepared to move on this work for 1.7.0 in the very short term? I
agree this is the right approach.
Re: Showstoppers to 1.7.0?
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Mar 13, 2019 at 11:47 AM Yann Ylavic <yl...@gmail.com> wrote:
>
> On Fri, Mar 8, 2019 at 9:19 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >
> > On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >>
> >> Do we want to do something about de-prioritizing sysv semaphores
> >> on linux by default with the 1.7.0 release?
> >
> > Comments? I know some distributors already hack around our default
> > autoconf locking mechanism choice on modern Linux.
>
> I'm +1 on this one, proc-pthread should be the default on linux (and
> possibly solaris too if not already the case).
Actually on all systems with both pthread_mutexattr_setpshared() and
pthread_mutexattr_setrobust[_np]().
ISTM that on some systems there is pthread_mutexattr_setrobust() w/o
the _np suffix (like *BSD), so we might want to check it for
HAVE_PTHREAD_MUTEX_ROBUST in apr_threads.m4 too..
Re: Showstoppers to 1.7.0?
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Mar 8, 2019 at 9:19 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> Do we want to do something about de-prioritizing sysv semaphores
>> on linux by default with the 1.7.0 release?
>
> Comments? I know some distributors already hack around our default
> autoconf locking mechanism choice on modern Linux.
I'm +1 on this one, proc-pthread should be the default on linux (and
possibly solaris too if not already the case).
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> With several new features added to the 1.7 branch, the fixes to the
> Netware locking we had deferred, and the proposed correction of
> SIGUSR2, I'm wondering what we see as remaining obstacles.
>
These two appear to be in good shape. Who has reviewed the addition
and further patches to the 64 bit portable atomics? Do we have a few
reviewers who agree these are good to lock down and publish?
I'd like to proceed with addressing the symlink vs. "other" reparse tag
> questions raised for Windows, and will make the time to get the current
> patch proposal and my type safety cleanups into trunk. PR 47630.
> I'm also interested in fixing SFU issues of the Ubuntu on Windows
> implementation with APR locking, and can dedicate a few hours
> this weekend to look at where those errors stand.
>
This weekend is looking good here for fixing the reparse tag questions
and further review of locking on the SFU Windows subsystem (by which
I mean, finally warmer, but much wetter and a good time to be indoors
in Chicagoland.)
Do we want to do something about de-prioritizing sysv semaphores
> on linux by default with the 1.7.0 release?
>
Comments? I know some distributors already hack around our default
autoconf locking mechanism choice on modern Linux.
I'd like to give this question a few more days, and finally lock down
our 1.7.0 candidate sometime later next week.
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> With several new features added to the 1.7 branch, the fixes to the
> Netware locking we had deferred, and the proposed correction of
> SIGUSR2, I'm wondering what we see as remaining obstacles.
>
> Do we want to do something about de-prioritizing sysv semaphores
> on linux by default with the 1.7.0 release?
>
AIUI only Yann and I are interested in this problem set, perhaps because
others long ago hacked around it in autoconf overrides? In any case,
this is the last issue that interested me. I didn't see any issues raised
w.r.t. APR (not APR-util) for a tag of 1.7.0.
Barring any other distraction, about 10am CDT this Friday I'd expect
to tag a first candidate as 1.7.0 and see if that flies. I'd love for many
of you to give the current state of ^/apr/apr/branches/1.7.x/ a whirl
and report (or fix) any irregularities.
I'm not proposing any tag of APR-util at this time.
Cheers,
Bill
Re: Showstoppers to 1.7.0?
Posted by "William Kimball Jr." <ww...@kimballstuff.com>.
On 2/27/2019 5:06 PM, William A Rowe Jr wrote:
> With several new features added to the 1.7 branch, the fixes to the
> Netware locking we had deferred, and the proposed correction of
> SIGUSR2, I'm wondering what we see as remaining obstacles.
>
> Any other concerns ahead of 1.7.0?
If I may propose: BZ62342 still applies to all versions of apr (2.x) /
apr-util (1.x) and is a major security gap. I'm happy to provide a
1.7-specific patch as I've already done so for 1.5 and 2.0 via BugZilla
(though, I have yet to see any mention of it being included in any
PRs). Risk is low with this patch; it is being manually applied and
distributed throughout two organizations. It has proven effective,
backward-compatible, and production-safe since May of last year.
If there's a better way to pitch/submit this other than as patch files
to a BugZilla record that I bring up every time someone wants a release,
I'd love to take part in that other process.
Thanks for any consideration,
William Kimball Jr.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: Showstoppers to 1.7.0?
Posted by Yann Ylavic <yl...@gmail.com>.
On Sun, Mar 24, 2019 at 11:14 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> AFAICT the very last 'nit' is our bad habit of using the deprecated readdir_r()/readdir64_t() functions in modern gcc. Comparing ./configure and make reminds me I had a kludge to finish in my working 1.7 tree. See https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html for a lengthy explanation.
How about r1856189?
Re: [poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Mar 28, 2019 at 4:55 PM Yann Ylavic <yl...@gmail.com> wrote:
>
> On Thu, Mar 28, 2019 at 4:19 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >
> > So... What is our preferred solution as of 1.7.0?
> >
> > 1. Drop readdir[64]_r for readdir[64] always.
> > 2. Allow readdir[64]_r with an autoconf toggle, skip detection.
> > 3. Override readdir[64]_r detection with a test of ldd --version >= 2.24
>
> How about http://svn.apache.org/r1856274 ?
>
> That's an autoconf to detect warnings when compiling readdir_r(), any
> warning but the simply main() shouldn't raise unrelated ones
> hopefully..., such that in this case we use readdir()?
Forgot to mention, it does not address readdir64_r(), what system is that?
Re: [poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Sounds great, good observations. Absent any other opinions, with that
resolved, I'm happy to tag and roll this afternoon to begin the release
vote.
On Fri, Mar 29, 2019, 04:26 Yann Ylavic <yl...@gmail.com> wrote:
> On Fri, Mar 29, 2019 at 5:01 AM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > Opinions?
>
> Anyway, our usage of readdir_r() is no more thread-safe than with the
> non-_r() version, because of the (struct dirent *)thedir->entry we
> pass to it (should be either on the stack or allocated for each
> apr_dir_read() call), or more generally because of our design of
> apr_dir_read() which does _not_ allow to call it concurrently with the
> same apr_dir_t (thus pool), like almost all of our designs.
>
> So readdir() vs readdir_r () is a non-issue to begin with IMHO (we use
> readdir_r() probably like readdir() is implemented), let's just
> silence the warning like in r1856274...
>
Re: [poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Mar 29, 2019 at 5:01 AM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Opinions?
Anyway, our usage of readdir_r() is no more thread-safe than with the
non-_r() version, because of the (struct dirent *)thedir->entry we
pass to it (should be either on the stack or allocated for each
apr_dir_read() call), or more generally because of our design of
apr_dir_read() which does _not_ allow to call it concurrently with the
same apr_dir_t (thus pool), like almost all of our designs.
So readdir() vs readdir_r () is a non-issue to begin with IMHO (we use
readdir_r() probably like readdir() is implemented), let's just
silence the warning like in r1856274...
Re: [poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Yes, that patch is option 2... and I would be alright with that choice.
Looking for consensus on which way we resolve this.
Opinions?
On Thu, Mar 28, 2019, 10:55 Yann Ylavic <yl...@gmail.com> wrote:
> On Thu, Mar 28, 2019 at 4:19 PM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > So... What is our preferred solution as of 1.7.0?
> >
> > 1. Drop readdir[64]_r for readdir[64] always.
> > 2. Allow readdir[64]_r with an autoconf toggle, skip detection.
> > 3. Override readdir[64]_r detection with a test of ldd --version >= 2.24
>
> How about http://svn.apache.org/r1856274 ?
>
> That's an autoconf to detect warnings when compiling readdir_r(), any
> warning but the simply main() shouldn't raise unrelated ones
> hopefully..., such that in this case we use readdir()?
>
Re: [poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Mar 28, 2019 at 4:19 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> So... What is our preferred solution as of 1.7.0?
>
> 1. Drop readdir[64]_r for readdir[64] always.
> 2. Allow readdir[64]_r with an autoconf toggle, skip detection.
> 3. Override readdir[64]_r detection with a test of ldd --version >= 2.24
How about http://svn.apache.org/r1856274 ?
That's an autoconf to detect warnings when compiling readdir_r(), any
warning but the simply main() shouldn't raise unrelated ones
hopefully..., such that in this case we use readdir()?
[poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
So to this question, glibc 2.24 is the first release to loudly deprecate
readdir_r.
https://www.sourceware.org/ml/libc-alpha/2016-08/msg00212.html
However, the docs summary mentioned below calls out reasons why readdir_r
was never a good thing.
So... What is our preferred solution as of 1.7.0?
1. Drop readdir[64]_r for readdir[64] always.
2. Allow readdir[64]_r with an autoconf toggle, skip detection.
3. Override readdir[64]_r detection with a test of ldd --version >= 2.24
I am leaning towards option 1 at this point, even as I was about to
implement 3.
On Sun, Mar 24, 2019, 18:13 William A Rowe Jr <wr...@rowe-clan.net> wrote:
> AFAICT the very last 'nit' is our bad habit of using the deprecated
> readdir_r()/readdir64_t() functions in modern gcc. Comparing ./configure
> and make reminds me I had a kludge to finish in my working 1.7 tree. See
> https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html
> for a lengthy explanation.
>
Re: Showstoppers to 1.7.0?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
AFAICT the very last 'nit' is our bad habit of using the deprecated
readdir_r()/readdir64_t() functions in modern gcc. Comparing ./configure
and make reminds me I had a kludge to finish in my working 1.7 tree. See
https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html
for a lengthy explanation.
If anyone knows of anything else to address before we attempt to T&R a
1.7.0 release, please holler in the next day (this plea has been a standing
request for nearly a month on the apr dev list.)
Pre-tag retests on obscure architectures, which may have been disrupted by
recent BSD/OSX fixes would be very much appreciated.
On Wed, Feb 27, 2019, 17:06 William A Rowe Jr <wr...@rowe-clan.net> wrote:
> With several new features added to the 1.7 branch, the fixes to the
> Netware locking we had deferred, and the proposed correction of
> SIGUSR2, I'm wondering what we see as remaining obstacles.
>
> I'd like to proceed with addressing the symlink vs. "other" reparse tag
> questions raised for Windows, and will make the time to get the current
> patch proposal and my type safety cleanups into trunk. PR 47630.
>
> I'm also interested in fixing SFU issues of the Ubuntu on Windows
> implementation with APR locking, and can dedicate a few hours
> this weekend to look at where those errors stand.
>
> Do we want to do something about de-prioritizing sysv semaphores
> on linux by default with the 1.7.0 release?
>
> Any other concerns ahead of 1.7.0?
>
> Cheers,
>
> Bill
>
>
>