On Mon, Jun 27, 2016 at 6:00 AM, Jens Schleusener < jens.schleuse...@t-online.de> wrote:
> On Fri, 24 Jun 2016, William A Rowe Jr wrote: > > On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener < >> jens.schleuse...@t-online.de> wrote: >> >> 1) Just a pure ./configure (probably equivalent to using the option > --enable-mods-shared=most) let produce the "make" (compared to the last > release 2.4.20) 86 modules instead 85 modules with the additional modules > > modules/core/.libs/mod_watchdog.so > modules/proxy/.libs/mod_proxy_hcheck.so > Yes, proposed (and accepted) that we change the watchdog default to enable at enable "most", as proxy_hcheck requires it. > and the omitted module > > modules/session/.libs/mod_session_crypto.so > > That may be expected. > Need to look at mod_session_crypto, I hadn't proposed mod_session changes, modules/session/config.m4 hasn't changed since 2.4.21 was tagged. acinclude.m4 changes may have had side effects, but unlikely. Once the whole "--enable-proxy" decision is made, others that followed this broken pattern need to be reevaluated, but that isn't a change for a 2.4.23 tag, since there should be no regression here. There is a simpler explanation, did you change the detected apr-util to one without apr_crypto (based on openssl) enabled? Ensure your apr-util build enabled openssl and is current (1.5). By the way the option --enable-mods-shared=all produces 103 modules and > --enable-mods-shared=reallyall 120 ones. > > 2) But for me surprising the option--enable-mods-shared=none seems to have > the same configuration effect as the option--enable-mods-shared=most > (producing 86 modules) respectively the option is ignored and the default > "most" is used. > > Similar for e.g. --enable-mods-shared='headers rewrite dav' (an example > from the documentation page > http://httpd.apache.org/docs/2.4/programs/configure.html) seems to > produce the same behaviour like --enable-mods-shared=most while I would > expect that only the three specified modules would be buillt. > > Odd, also arbitray module names like --enable-mods-shared=nonsense seems > equivalent to --enable-mods-shared=most. > > But that is an error it seems not a regression since 2.4.20 shows the same > behaviour. > It is, you found it, and the error was already a side effect within acinclude.m4 which trusted the value 'no' (which is why I continued to trust the value 'no'). In order for --enable-mods-shared=nonsense to behave as expected, I think the patch is pretty simple... --- acinclude.m4 (revision 1749925) +++ acinclude.m4 (working copy) @@ -375,6 +375,8 @@ "$force_$1" != "no" ; then enable_$1=$module_default _apmod_extra_msg=" ($module_selection)" + else + enable_$1=no fi if test "$enable_$1" != "no"; then dnl If we plan to enable it, allow the module to run some autoconf magic
