On Mon, Jun 5, 2017 at 6:07 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > On Jun 3, 2017 13:36, "Yann Ylavic" <ylavic....@gmail.com> wrote: > > > #if 0 > /* We need to change apr_os_proc_mutex_t to a pointer type > * to be able to implement this function. > @@ -141,6 +138,11 @@ APR_DECLARE(apr_status_t) apr_os_proc_mutex_get_ex > *mech = APR_LOCK_DEFAULT; > } > return APR_SUCCESS; > +#else > + /* ENOTIMPL could be more meaningful, ENOLOCK is what 1.x has > + * always returned... From 2.x, the API issue is fixed. > + */ > + return APR_ENOLOCK; > #endif > } > > > Can I challenge your assumpion here for 1.7.x? > > You are reading a change in apr_proc_mutex_t and apr_os_proc_mutex_t as a > binary breaking change.
I didn't that feel this change : -typedef NXMutex_t apr_os_proc_mutex_t; +typedef NXMutex_t* apr_os_proc_mutex_t; was a "minor" change. > > But if you consider that apr's type is opaque, and that the underlying > system apr_os_proc_mutex_t could not be _get or _set through 1.6.x, then the > apr_os_proc_mutex_t on Netware was simply unused. But I'd like to concur to this point of view! > Is there an actual > versioning conflict correcting the type declaration on Netware so these work > from 1.7.0 forwards? What do you mean by "versioning conflict"? If everyone is fine with the above type change (which can only fix things, I don't see either how current apr_os_proc_mutex_t on netware can be used), I'm very much for it to go to 1.7 (and even 1.6, why not?)...
