mod_p hooks the post_config more than once, including really_last. mod_s's
post_config has to run after mod_p's post_config (both of them) for one of
its features to work. I tried adding "mod_p.c" to the predecessor list in
mod_s, but it wasn't effective, as predecessor processing doesn't account
for the possibility that the predecessor may have hooked more than once.
No claims here to understand all the hook sorting; I found some code that I
was expecting, changed it, was happy, changed the LoadModule order, was
still happy, but noted that there's some other, less obvious code that
touches predecessors too (tsort()).
Any thoughts before I test in more detail?
Index: hooks/apr_hooks.c
===================================================================
--- hooks/apr_hooks.c (revision 773522)
+++ hooks/apr_hooks.c (working copy)
@@ -96,8 +96,9 @@
for(n=0 ; n < nItems ; ++n) {
int i,k;
+ /* stop at last instance of a predecessor if present multiple times */
for(i=0 ; pItems[n].aszPredecessors && pItems[n].aszPredecessors[i] ;
++i)
- for(k=0 ; k < nItems ; ++k)
+ for(k=nItems-1 ; k >= 0 ; --k)
if(!strcmp(pItems[k].szName,pItems[n].aszPredecessors[i])) {
int l;
@@ -109,6 +110,7 @@
got_it:
break;
}
+ /* stop at first instance of a successor if present multiple times */
for(i=0 ; pItems[n].aszSuccessors && pItems[n].aszSuccessors[i] ; ++i)
for(k=0 ; k < nItems ; ++k)
if(!strcmp(pItems[k].szName,pItems[n].aszSuccessors[i])) {
