Re: Current trunk does not build on Win
Thanks! Bill, Building fine with r1829381 and initial tests looking ok. On Tuesday 17/04/2018 at 19:57, William A Rowe Jr wrote: On Mon, Apr 16, 2018 at 8:37 AM, Steffen wrote: I like to continue building/testing trunk. Is there a fix coming ? I guess not from the author. Try r1829381 now committed to trunk. If that doesn't work, we'll revert and start again, no cycles to check the fix myself.
Re: Current trunk does not build on Win
On Mon, Apr 16, 2018 at 8:37 AM, Steffen wrote: > > I like to continue building/testing trunk. > > Is there a fix coming ? I guess not from the author. Try r1829381 now committed to trunk. If that doesn't work, we'll revert and start again, no cycles to check the fix myself.
Re: Current trunk does not build on Win
I like to continue building/testing trunk. Is there a fix coming ? On 2018/04/10 18:13:19, Eric Covener wrote: > > But why is this an issue? grep -r output_pending in 2.4.x branch> > > in modules/... and server/... shows me nothing. No problem with> > > an MMN major change on 2.5 branch.> > > Ah good point.> > > -- > > Eric Covener> > cove...@gmail.com> >
Re: Current trunk does not build on Win
> But why is this an issue? grep -r output_pending in 2.4.x branch > in modules/... and server/... shows me nothing. No problem with > an MMN major change on 2.5 branch. Ah good point. -- Eric Covener cove...@gmail.com
Re: Current trunk does not build on Win
To thoroughly confuse... On Tue, Apr 10, 2018 at 10:49 AM, Eric Covener wrote: > On Tue, Apr 10, 2018 at 11:40 AM, William A Rowe Jr > wrote: >> On Tue, Apr 10, 2018 at 7:41 AM, Steffen wrote: >>> >>> Get: >>> >>> Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)' >>> to 'ap_HOOK_output_pending_t (__cdecl *)' libhttpd >>> ..\VC15\trunk\server\core.c 5724 >> >> '(__stdcall *)(conn_rec *)' != '(__cdecl *) (conn_rec *)' >> >> Callback entry points are generally declared AP_DECLARE_NONSTD >> for this reason. > > It looks like the mod_ssl pattern is that it is not decorated at all. > mod_ssl is the closest to this since it registers non-static functions > from other C files. > They are undecorated. For any non-exported function, undecorated is NONSTD (just not declared). For exported functions, AP_DECLARE "promotes" these to the stdcall API (consistent with most languages default stack args and retval manipulation (except C/C++/ASM). So one can read AP_DECLARE_NONSTD as going right back to the same C/C++ mechanics, only with an exported entry point. Those individual hook callbacks in ssl are static, and registered in an initializer within the same source file. In the declaration static apr_status_t ssl_io_filter_output(ap_filter_t *f, ... this would become SSL_DECLARE_NONSTD(apr_status_t) ssl_io_filter_output(ap_filter_t *f, ... to maintain the very same conventions as previous releases (now with an exported symbol). > ...But we already have this thing in util_filter with AP_DECLARE. > Do we need to wrap it to effectively change to NONSTD or undecorated > for what we register w/ ap_hook_* since it is already public as > AP_DECLARE? Pondering. Right now the stack unwinds would be ridiculous... would substitute the AP_DECLARE with an AP_DECLARE_NONSTD() fn_nonstd() flavor, and then have the originally named function invoke _nonstd(). But why is this an issue? grep -r output_pending in 2.4.x branch in modules/... and server/... shows me nothing. No problem with an MMN major change on 2.5 branch.
Re: Current trunk does not build on Win
On Tue, Apr 10, 2018 at 11:40 AM, William A Rowe Jr wrote: > On Tue, Apr 10, 2018 at 7:41 AM, Steffen wrote: >> >> Get: >> >> Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)' >> to 'ap_HOOK_output_pending_t (__cdecl *)' libhttpd >> ..\VC15\trunk\server\core.c 5724 > > '(__stdcall *)(conn_rec *)' != '(__cdecl *) (conn_rec *)' > > Callback entry points are generally declared AP_DECLARE_NONSTD > for this reason. It looks like the mod_ssl pattern is that it is not decorated at all. mod_ssl is the closest to this since it registers non-static functions from other C files. They are undecorated. ...But we already have this thing in util_filter with AP_DECLARE. Do we need to wrap it to effectively change to NONSTD or undecorated for what we register w/ ap_hook_* since it is already public as AP_DECLARE? -- Eric Covener cove...@gmail.com
Re: Current trunk does not build on Win
On Tue, Apr 10, 2018 at 7:41 AM, Steffen wrote: > > Get: > > Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)' > to 'ap_HOOK_output_pending_t (__cdecl *)' libhttpd > ..\VC15\trunk\server\core.c 5724 '(__stdcall *)(conn_rec *)' != '(__cdecl *) (conn_rec *)' Callback entry points are generally declared AP_DECLARE_NONSTD for this reason.
Current trunk does not build on Win
Get: Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)' to 'ap_HOOK_output_pending_t (__cdecl *)' libhttpd ..\VC15\trunk\server\core.c 5724 When I remove the hook in core.c : ap_hook_output_pending(ap_filter_output_pending, NULL, NULL, APR_HOOK_MIDDLE); Then it build and runs.
