On Mon, 27 Jun 2016, William A Rowe Jr wrote:
On Mon, Jun 27, 2016 at 6:00 AM, Jens Schleusener
<[email protected]> wrote:
On Fri, 24 Jun 2016, William A Rowe Jr wrote:
On Thu, Jun 23, 2016 at 10:38 AM, Jens Schleusener
<[email protected]>
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).
Oops, my fault, well combined, you are completely right: For 2.4.20 I
used (since I have originally not downloaded httpd-2.4.20-deps.tar.bz2)
my "separate" self-compiled apr-1.5.2 and apr-util-1.5.4
installatations (using the configure options --with-crypto
--with-openssl=/usr).
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
Just for completeness (since another fix seems on the way): At some first
quick tests this fix seems not to work for me. For httpd-2.4.x I saw no
difference in the number of built modules using either
--enable-mods-shared=nonsense or --enable-mods-shared=none and for
httpd-2.4.21 (patched with your proxy-rollup-2.4.21.patch patch) it let
only omit the modules
modules/proxy/balancers/.libs/mod_lbmethod_bybusyness.so
modules/proxy/balancers/.libs/mod_lbmethod_byrequests.so
modules/proxy/balancers/.libs/mod_lbmethod_bytraffic.so
modules/proxy/balancers/.libs/mod_lbmethod_heartbeat.so
Regards
Jens
