You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ruediger Pluem <rp...@apache.org> on 2009/05/05 21:08:45 UTC
Re: svn commit: r771940 - in /httpd/httpd/trunk/modules/proxy: ./
balancers/ examples/
On 05/05/2009 07:15 PM, jfclere@apache.org wrote:
> Author: jfclere
> Date: Tue May 5 17:15:48 2009
> New Revision: 771940
>
> URL: http://svn.apache.org/viewvc?rev=771940&view=rev
> Log:
> Change the order of mod_proxy and mod_proxy_balancer child_init().
> Change the balancer workers area to the address of workers instead copying the workers.
> Arrange lbmethod accordingly.
> Move the creation of conf->forward worker to mod_proxy child_init().
>
> Modified:
> httpd/httpd/trunk/modules/proxy/balancers/mod_lbmethod_bybusyness.c
> httpd/httpd/trunk/modules/proxy/balancers/mod_lbmethod_byrequests.c
> httpd/httpd/trunk/modules/proxy/balancers/mod_lbmethod_bytraffic.c
> httpd/httpd/trunk/modules/proxy/balancers/mod_lbmethod_heartbeat.c
> httpd/httpd/trunk/modules/proxy/examples/mod_lbmethod_rr.c
> httpd/httpd/trunk/modules/proxy/mod_proxy.c
> httpd/httpd/trunk/modules/proxy/mod_proxy.h
> httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
> httpd/httpd/trunk/modules/proxy/proxy_util.c
>
> @@ -1471,13 +1471,13 @@
>
> PROXY_DECLARE(void)
> ap_proxy_add_worker_to_balancer(apr_pool_t *pool, proxy_balancer *balancer,
> - proxy_worker *worker)
> + proxy_worker **worker)
IMHO providing *worker as the old code does is sufficient.
> {
> - proxy_worker *runtime;
> + proxy_worker **runtime;
>
> runtime = apr_array_push(balancer->workers);
> - memcpy(runtime, worker, sizeof(proxy_worker));
> - runtime->id = proxy_lb_workers;
> + memcpy(runtime, worker, sizeof(proxy_worker *));
Do we really need memcpy here? Shouldn't
*runtime = *worker
be sufficient or in the case that we go back to the old
function prototype shouldn't
*runtime = worker
be enough?
Regards
Rüdiger
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
> The issue happend on RHEL 4 64 Bit.
FWIW - FC10 x86_64 is my own default testing schema.
Re: svn commit: r771998
Posted by Ruediger Pluem <rp...@apache.org>.
On 05/06/2009 09:54 PM, William A. Rowe, Jr. wrote:
> Plüm, Rüdiger, VF-Group wrote:
>> This causes trunk to fail compilation with:
>>
>> make[1]: *** No rule to make target `modules/mappers/libmod_so.la', needed by `httpd'. Stop.
>> make: *** [all-recursive] Error 1
>
> Please don't do that, you have everyone chasing down if they owned 771998.
> At least leave a log message with your reply to spare most folks attention.
Sorry for that I didn't have the original svn mail at hand at this point of time.
Will improve my communication next time in the same situation.
>
> ITMT; I'm reviewing. I didn't see this on retesting linux, will try clean
> on Solaris just for fun (and for the fact that I think I have this VM ready
> for some action).
>
> You did re-./buildconf, make clean and make, right?
Sure. To be more precise I did
make extraclean
./buidlconf
./config.nice
make
The issue happend on RHEL 4 64 Bit.
The same happens on SuSE 10.2 32 Bit.
Regards
Rüdiger
Re: svn commit: r771998
Posted by Deputy Director General <dy...@myanmar.com.mm>.
Please stop your sending email to me.
Thank you.
----- Original Message -----
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
To: "William A. Rowe, Jr." <wr...@rowe-clan.net>; <de...@httpd.apache.org>
Sent: Thursday, May 07, 2009 10:36 PM
Subject: Re: svn commit: r771998
> Joe Orton wrote:
>>
>> Hah - please explain motivation for changes in the changelog message,
>> likewise!
>
> It appeared that the choice of config9 was deliberate. Going on the
> assumption that this was not, and dropping the entire directory back
> to config2 to test this theory.
>
>> It's broken because there are two config*.m4 files in modules/mappers
>> now which both call APACHE_MODPATH_INIT/FINISH for the same directory.
>> The config9.m4 hence blows away the modules.mk set up for mod_so.
>
> Understood. config2 is required. config9 may not be.
>
> Anyone recall the motivation?
>
>
Re: svn commit: r771998
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, May 11, 2009 at 11:18 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net>wrote:
> William A. Rowe, Jr. wrote:
> > Roy T. Fielding wrote:
> >> On May 7, 2009, at 10:57 PM, William A. Rowe, Jr. wrote:
> >>> In any case, I have a better solution. mod_so is not a URI mapper, nor
> >>> is mod_watchdog. I created a modules/core/ tree; fixed.
> >> Why do people always want to use "core" as a directory name?
> >> "sys" or "systemic" would be better, or just move each to its
> >> own directory.
> >
> > I feel the same way about /debug/ :) support also might not be a bad
> > choice, except that support/ and modules/support/ could get confusing.
> >
> > Any other suggestions for modules exporting central functionality?
> > hub/?
>
> modules/process/ ?
>
modules/services?
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Roy T. Fielding wrote:
>> On May 7, 2009, at 10:57 PM, William A. Rowe, Jr. wrote:
>>> In any case, I have a better solution. mod_so is not a URI mapper, nor
>>> is mod_watchdog. I created a modules/core/ tree; fixed.
>> Why do people always want to use "core" as a directory name?
>> "sys" or "systemic" would be better, or just move each to its
>> own directory.
>
> I feel the same way about /debug/ :) support also might not be a bad
> choice, except that support/ and modules/support/ could get confusing.
>
> Any other suggestions for modules exporting central functionality?
> hub/?
modules/process/ ?
Anyone with a good idea?
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
> On May 7, 2009, at 10:57 PM, William A. Rowe, Jr. wrote:
>> In any case, I have a better solution. mod_so is not a URI mapper, nor
>> is mod_watchdog. I created a modules/core/ tree; fixed.
>
> Why do people always want to use "core" as a directory name?
> "sys" or "systemic" would be better, or just move each to its
> own directory.
I feel the same way about /debug/ :) support also might not be a bad
choice, except that support/ and modules/support/ could get confusing.
Any other suggestions for modules exporting central functionality?
hub/?
Re: svn commit: r771998
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On May 7, 2009, at 10:57 PM, William A. Rowe, Jr. wrote:
> In any case, I have a better solution. mod_so is not a URI mapper,
> nor
> is mod_watchdog. I created a modules/core/ tree; fixed.
Why do people always want to use "core" as a directory name?
"sys" or "systemic" would be better, or just move each to its
own directory.
....Roy
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
>
> disagree, there is still a load order issue between mod_watchdog and
> any modules using the api, we should not do that.
And what of mod_dav? svn rm it?
Same problem set; the new schema sets up watchdog at config2; if you want
to consume it's API (as modules/cluster/ does) fix your config later.
Improve this? Sure be our guest, Jeff and I will feel a little guilty
watching you do it :) But you can't complain that the API is invalid
when the very same problem set exists throughout the code base.
Re: svn commit: r771998
Posted by Paul Querna <pa...@querna.org>.
On Fri, May 8, 2009 at 1:49 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Ruediger Pluem wrote:
>>
>> On 05/08/2009 07:09 PM, William A. Rowe, Jr. wrote:
>>> Plüm, Rüdiger, VF-Group wrote:
>>>> "--enable-mods-shared=all" \
>>> And what is/was your last httpd -l
>>
>> Compiled in modules:
>> core.c
>> http_core.c
>> worker.c
>> mod_so.c
>
> This is extremely odd. Review your config.m4, it is insisting
> on including the cluster/ modules statically.
>
> Hmmm, have you rm -rf'ed config.status? Have you tried removing
> mod_watchdog from the list and simply letting it compile in (all),
> then reverify the newest httpd -l?
>
> Something is simply strange in your config.
>
disagree, there is still a load order issue between mod_watchdog and
any modules using the api, we should not do that.
Re: svn commit: r771998
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, May 8, 2009 at 11:41 AM, William A. Rowe, Jr.
<wr...@rowe-clan.net>wrote:
> Jeff Trawick wrote:
> >
> > anyway, I think we should address any such ordering problems by axing
> > the export of raw functions
>
> FWIW I don't disagree, I just don't have time to invest in it
yeah; I felt at least a tiny bit guilty suggesting this a couple of times
instead of just doing it ;)
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
> I found it: There was a stray config.m4 located in my modules/cluster
> directory. I guess it got there during my tries to fix the issue and
> I missed to delete it afterwards.
> Thanks for your extensive help and sorry for the noise.
No bother; fyi a personal favorite (as long as you have no extra working
files that you had forgotten to svn add) is;
svn status --no-ignore | awk "/^[I\?]/{print \$2}" | xargs rm
Re: svn commit: r771998
Posted by Ruediger Pluem <rp...@apache.org>.
On 05/08/2009 10:49 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>> On 05/08/2009 07:09 PM, William A. Rowe, Jr. wrote:
>>> Plüm, Rüdiger, VF-Group wrote:
>>>> "--enable-mods-shared=all" \
>>> And what is/was your last httpd -l
>> Compiled in modules:
>> core.c
>> http_core.c
>> worker.c
>> mod_so.c
>
> This is extremely odd. Review your config.m4, it is insisting
> on including the cluster/ modules statically.
>
> Hmmm, have you rm -rf'ed config.status? Have you tried removing
> mod_watchdog from the list and simply letting it compile in (all),
> then reverify the newest httpd -l?
>
> Something is simply strange in your config.
I found it: There was a stray config.m4 located in my modules/cluster
directory. I guess it got there during my tries to fix the issue and
I missed to delete it afterwards.
Thanks for your extensive help and sorry for the noise.
Regards
Rüdiger
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ruediger Pluem wrote:
>
> On 05/08/2009 07:09 PM, William A. Rowe, Jr. wrote:
>> Plüm, Rüdiger, VF-Group wrote:
>>> "--enable-mods-shared=all" \
>> And what is/was your last httpd -l
>
> Compiled in modules:
> core.c
> http_core.c
> worker.c
> mod_so.c
This is extremely odd. Review your config.m4, it is insisting
on including the cluster/ modules statically.
Hmmm, have you rm -rf'ed config.status? Have you tried removing
mod_watchdog from the list and simply letting it compile in (all),
then reverify the newest httpd -l?
Something is simply strange in your config.
Re: svn commit: r771998
Posted by Ruediger Pluem <rp...@apache.org>.
On 05/08/2009 07:09 PM, William A. Rowe, Jr. wrote:
> Plüm, Rüdiger, VF-Group wrote:
>> "--enable-mods-shared=all" \
>
> And what is/was your last httpd -l
Compiled in modules:
core.c
http_core.c
worker.c
mod_so.c
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Plüm, Rüdiger, VF-Group wrote:
> "--enable-mods-shared=all" \
And what is/was your last httpd -l
IIRC, --enable-mods-shared does not override your -enable-mod
Re: svn commit: r771998
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: William A. Rowe, Jr.
> Gesendet: Freitag, 8. Mai 2009 18:52
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r771998
>
> Plüm, Rüdiger, VF-Group wrote:
> >
> > I had not, but the same result with it.
>
> EMISMATCH; you can't enable-static mod_dav_fs using dynamic
> mod_dav, and
> you can't enable heartbeat/heartmonitor static using dynamic
> mod_watchdog.
>
> What is your ./configure?
>
#! /bin/sh
#
# Created by configure
CFLAGS="-Wall -g -O2"; export CFLAGS
"./configure" \
"--prefix=/home/pluem/apache/apache_trunk" \
"--enable-mods-shared=all" \
"--with-ldap" \
"--enable-proxy" \
"--enable-proxy-connect" \
"--enable-proxy-ftp" \
"--enable-proxy-http" \
"--enable-proxy-ajp" \
"--enable-proxy-balancer" \
"--enable-ssl" \
"--enable-cache" \
"--enable-disk-cache" \
"--enable-ldap" \
"--enable-authnz-ldap" \
"--enable-file-cache" \
"--enable-dav-lock" \
"--with-mpm=worker" \
"--enable-authn-alias" \
"--enable-pie" \
"--enable-substitute" \
"--enable-case_filter_in" \
"--enable-case_filter" \
"--enable-echo" \
"--enable-bucketeer" \
"--enable-cgi" \
"--with-mysql" \
"--enable-watchdog" \
"CFLAGS=-Wall -g -O2" \
"$@"
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Plüm, Rüdiger, VF-Group wrote:
>
> I had not, but the same result with it.
EMISMATCH; you can't enable-static mod_dav_fs using dynamic mod_dav, and
you can't enable heartbeat/heartmonitor static using dynamic mod_watchdog.
What is your ./configure?
Re: svn commit: r771998
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: William A. Rowe, Jr.
> Gesendet: Freitag, 8. Mai 2009 18:24
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r771998
>
> Plüm, Rüdiger, VF-Group wrote:
> > Tried all that it still fails to build:
> >
> >
> modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.tex
> t+0x2a5): In function `hb_register_hooks':
> >
> /home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c
> :153: undefined reference to `ap_hook_watchdog_need'
> >
> modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.tex
> t+0x2ba):/home/pluem/apache/httpd-trunk/modules/cluster/mod_he
> artbeat.c:154: undefined reference to `ap_hook_watchdog_init'
> >
> modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.tex
> t+0x2cf):/home/pluem/apache/httpd-trunk/modules/cluster/mod_he
> artbeat.c:155: undefined reference to `ap_hook_watchdog_step'
> >
> modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.tex
> t+0x2e8):/home/pluem/apache/httpd-trunk/modules/cluster/mod_he
> artbeat.c:156: undefined reference to `ap_hook_watchdog_exit'
> >
> modules/cluster/.libs/libmod_heartmonitor.a(mod_heartmonitor.o
> )(.text+0x956): In function `hm_post_config':
> >
> /home/pluem/apache/httpd-trunk/modules/cluster/mod_heartmonito
> r.c:395: undefined reference to `ap_watchdog_get_instance'
> >
> modules/cluster/.libs/libmod_heartmonitor.a(mod_heartmonitor.o
> )(.text+0x96f):/home/pluem/apache/httpd-trunk/modules/cluster/
> mod_heartmonitor.c:405: undefined reference to
> `ap_watchdog_register_callback'
> > collect2: ld returned 1 exit status
> > make[1]: *** [httpd] Error 1
>
> Ok; makes perfect sense, you aren't using the default libtool schema,
> or perhaps you have a --no-undefined hiding somewhere?
>
> What's especially strange; you are able to build mod_dav_fs?
Yes, I can.
> It consumes
> exports from mod_dav (modules/dav/main/).
>
> What do your modules/dav/fs/modules.mk and
> modules/cluster/modules.mk look
mod_dav_fs.la: mod_dav_fs.slo dbm.slo lock.slo repos.slo
$(SH_LINK) -rpath $(libexecdir) -module -avoid-version mod_dav_fs.lo dbm.lo lock.lo repos.lo $(MOD_DAV_FS_LDADD)
DISTCLEAN_TARGETS = modules.mk
static =
shared = mod_dav_fs.la
libmod_heartbeat.la: mod_heartbeat.lo
$(MOD_LINK) mod_heartbeat.lo $(MOD_HEARTBEAT_LDADD)
libmod_heartmonitor.la: mod_heartmonitor.lo
$(MOD_LINK) mod_heartmonitor.lo $(MOD_HEARTMONITOR_LDADD)
DISTCLEAN_TARGETS = modules.mk
static = libmod_heartbeat.la libmod_heartmonitor.la
shared =
> like? What are the values of MOD_DAV_FS_LDADD and
> MOD_HEARTBEAT_LDADD?
>From build/config_vars.mk:
MOD_HEARTBEAT_LDADD =
MOD_HEARTMONITOR_LDADD =
MOD_DAV_LDADD =
MOD_STATUS_LDADD =
MOD_AUTOINDEX_LDADD =
MOD_ASIS_LDADD =
MOD_INFO_LDADD =
MOD_CGI_LDADD =
MOD_DAV_FS_LDADD =
>
> Actually, I have a really stupid question; did you
> --enable-watchdog ???
I had not, but the same result with it.
Regards
Rüdiger
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Plüm, Rüdiger, VF-Group wrote:
> Tried all that it still fails to build:
>
> modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2a5): In function `hb_register_hooks':
> /home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:153: undefined reference to `ap_hook_watchdog_need'
> modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2ba):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:154: undefined reference to `ap_hook_watchdog_init'
> modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2cf):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:155: undefined reference to `ap_hook_watchdog_step'
> modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2e8):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:156: undefined reference to `ap_hook_watchdog_exit'
> modules/cluster/.libs/libmod_heartmonitor.a(mod_heartmonitor.o)(.text+0x956): In function `hm_post_config':
> /home/pluem/apache/httpd-trunk/modules/cluster/mod_heartmonitor.c:395: undefined reference to `ap_watchdog_get_instance'
> modules/cluster/.libs/libmod_heartmonitor.a(mod_heartmonitor.o)(.text+0x96f):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartmonitor.c:405: undefined reference to `ap_watchdog_register_callback'
> collect2: ld returned 1 exit status
> make[1]: *** [httpd] Error 1
Ok; makes perfect sense, you aren't using the default libtool schema,
or perhaps you have a --no-undefined hiding somewhere?
What's especially strange; you are able to build mod_dav_fs? It consumes
exports from mod_dav (modules/dav/main/).
What do your modules/dav/fs/modules.mk and modules/cluster/modules.mk look
like? What are the values of MOD_DAV_FS_LDADD and MOD_HEARTBEAT_LDADD?
Actually, I have a really stupid question; did you --enable-watchdog ???
Re: svn commit: r771998
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: William A. Rowe, Jr.
> Gesendet: Freitag, 8. Mai 2009 17:42
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r771998
>
> Jeff Trawick wrote:
> >
> > anyway, I think we should address any such ordering
> problems by axing
> > the export of raw functions
>
> FWIW I don't disagree, I just don't have time to invest in
> it, and it seems
> this was added to core/compiled-in-by-force without much discussion.
>
> Looking at exports.c right now, I suspect this could be stale files in
> Rudiger's build, because it is working as-expected.
It doesn't work even if I delete exports.c explicitly and let it be generated
freshly.
>
> Again; make clean; ./buildconf; ./configure; make is
I did the same with make extraclean instead of make clean.
> required, and this
> should clean out any stale generated exports.
>
> Failing that, try rm include/mod_watchdog.h core/export* and
> then rebuild.
Tried all that it still fails to build:
modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2a5): In function `hb_register_hooks':
/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:153: undefined reference to `ap_hook_watchdog_need'
modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2ba):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:154: undefined reference to `ap_hook_watchdog_init'
modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2cf):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:155: undefined reference to `ap_hook_watchdog_step'
modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2e8):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:156: undefined reference to `ap_hook_watchdog_exit'
modules/cluster/.libs/libmod_heartmonitor.a(mod_heartmonitor.o)(.text+0x956): In function `hm_post_config':
/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartmonitor.c:395: undefined reference to `ap_watchdog_get_instance'
modules/cluster/.libs/libmod_heartmonitor.a(mod_heartmonitor.o)(.text+0x96f):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartmonitor.c:405: undefined reference to `ap_watchdog_register_callback'
collect2: ld returned 1 exit status
make[1]: *** [httpd] Error 1
Regards
Rüdiger
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
>
> anyway, I think we should address any such ordering problems by axing
> the export of raw functions
FWIW I don't disagree, I just don't have time to invest in it, and it seems
this was added to core/compiled-in-by-force without much discussion.
Looking at exports.c right now, I suspect this could be stale files in
Rudiger's build, because it is working as-expected.
Again; make clean; ./buildconf; ./configure; make is required, and this
should clean out any stale generated exports.
Failing that, try rm include/mod_watchdog.h core/export* and then rebuild.
Also, note you are going to need to rm /{prefix}/httpd.conf before you
make install or the mod_watchdog.so is not going to be in your load module
list at all.
Re: svn commit: r771998
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Jeff Trawick
> Gesendet: Freitag, 8. Mai 2009 12:59
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r771998
>
> On Fri, May 8, 2009 at 6:49 AM, "Plüm, Rüdiger, VF-Group"
> <ru...@vodafone.com> wrote:
>
>
>
>
> I guess this is because mod_watchdog is now build
> dynamically and mod_watchdog is not
> stored in includes/.
> So I guess we either need to do that or rewrite the
> watchdog to be either provider
> or optional functions based.
>
>
> that's a link-time error, so includes/ doesn't matter, right?
IMHO it does because the header files in includes are picked up to build exports.c
Regards
Rüdiger
Re: svn commit: r771998
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, May 8, 2009 at 6:49 AM, "Plüm, Rüdiger, VF-Group" <
ruediger.pluem@vodafone.com> wrote:
>
>
> I guess this is because mod_watchdog is now build dynamically and
> mod_watchdog is not
> stored in includes/.
> So I guess we either need to do that or rewrite the watchdog to be either
> provider
> or optional functions based.
that's a link-time error, so includes/ doesn't matter, right?
anyway, I think we should address any such ordering problems by axing the
export of raw functions
Re: svn commit: r771998
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: William A. Rowe, Jr.
> Gesendet: Freitag, 8. Mai 2009 07:57
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r771998
>
> William A. Rowe, Jr. wrote:
> > Joe Orton wrote:
> >> Hah - please explain motivation for changes in the
> changelog message,
> >> likewise!
> >
> > It appeared that the choice of config9 was deliberate. Going on the
> > assumption that this was not, and dropping the entire directory back
> > to config2 to test this theory.
> >
> >> It's broken because there are two config*.m4 files in
> modules/mappers
> >> now which both call APACHE_MODPATH_INIT/FINISH for the
> same directory.
> >> The config9.m4 hence blows away the modules.mk set up for mod_so.
> >
> > Understood. config2 is required. config9 may not be.
> >
> > Anyone recall the motivation?
>
> In any case, I have a better solution. mod_so is not a URI
> mapper, nor
> is mod_watchdog. I created a modules/core/ tree; fixed.
Trunk build is still broken or better mod_heartbeat and mod_heartmonitor
don't build :-(:
modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2a5): In function `hb_register_hooks':
/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:153: undefined reference to `ap_hook_watchdog_need'
modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2ba):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:154: undefined reference to `ap_hook_watchdog_init'
modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2cf):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:155: undefined reference to `ap_hook_watchdog_step'
modules/cluster/.libs/libmod_heartbeat.a(mod_heartbeat.o)(.text+0x2e8):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartbeat.c:156: undefined reference to `ap_hook_watchdog_exit'
modules/cluster/.libs/libmod_heartmonitor.a(mod_heartmonitor.o)(.text+0x956): In function `hm_post_config':
/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartmonitor.c:395: undefined reference to `ap_watchdog_get_instance'
modules/cluster/.libs/libmod_heartmonitor.a(mod_heartmonitor.o)(.text+0x96f):/home/pluem/apache/httpd-trunk/modules/cluster/mod_heartmonitor.c:405: undefined reference to `ap_watchdog_register_callback'
collect2: ld returned 1 exit status
make[1]: *** [httpd] Error 1
make: *** [all-recursive] Error 1
I guess this is because mod_watchdog is now build dynamically and mod_watchdog is not
stored in includes/.
So I guess we either need to do that or rewrite the watchdog to be either provider
or optional functions based.
Regards
Rüdiger
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
> Joe Orton wrote:
>> Hah - please explain motivation for changes in the changelog message,
>> likewise!
>
> It appeared that the choice of config9 was deliberate. Going on the
> assumption that this was not, and dropping the entire directory back
> to config2 to test this theory.
>
>> It's broken because there are two config*.m4 files in modules/mappers
>> now which both call APACHE_MODPATH_INIT/FINISH for the same directory.
>> The config9.m4 hence blows away the modules.mk set up for mod_so.
>
> Understood. config2 is required. config9 may not be.
>
> Anyone recall the motivation?
In any case, I have a better solution. mod_so is not a URI mapper, nor
is mod_watchdog. I created a modules/core/ tree; fixed.
Happy to entertain any better directory name than modules/core/ if someone
has a good suggestion as to how we should group such modules?
Note that the build is broken right now for mod_lua; it indiscriminately
adds /usr/lib without asking pkgconfig what to do, first :)
Bill
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
> Hah - please explain motivation for changes in the changelog message,
> likewise!
It appeared that the choice of config9 was deliberate. Going on the
assumption that this was not, and dropping the entire directory back
to config2 to test this theory.
> It's broken because there are two config*.m4 files in modules/mappers
> now which both call APACHE_MODPATH_INIT/FINISH for the same directory.
> The config9.m4 hence blows away the modules.mk set up for mod_so.
Understood. config2 is required. config9 may not be.
Anyone recall the motivation?
Re: svn commit: r771998
Posted by Joe Orton <jo...@redhat.com>.
On Wed, May 06, 2009 at 02:54:59PM -0500, William Rowe wrote:
> Plüm, Rüdiger, VF-Group wrote:
> >
> > This causes trunk to fail compilation with:
> >
> > make[1]: *** No rule to make target `modules/mappers/libmod_so.la', needed by `httpd'. Stop.
> > make: *** [all-recursive] Error 1
>
> Please don't do that, you have everyone chasing down if they owned 771998.
> At least leave a log message with your reply to spare most folks attention.
Hah - please explain motivation for changes in the changelog message,
likewise!
It's broken because there are two config*.m4 files in modules/mappers
now which both call APACHE_MODPATH_INIT/FINISH for the same directory.
The config9.m4 hence blows away the modules.mk set up for mod_so.
Joe
Re: svn commit: r771998
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Plüm, Rüdiger, VF-Group wrote:
>
> This causes trunk to fail compilation with:
>
> make[1]: *** No rule to make target `modules/mappers/libmod_so.la', needed by `httpd'. Stop.
> make: *** [all-recursive] Error 1
Please don't do that, you have everyone chasing down if they owned 771998.
At least leave a log message with your reply to spare most folks attention.
ITMT; I'm reviewing. I didn't see this on retesting linux, will try clean
on Solaris just for fun (and for the fact that I think I have this VM ready
for some action).
You did re-./buildconf, make clean and make, right?
Re: svn commit: r771998
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
This causes trunk to fail compilation with:
make[1]: *** No rule to make target `modules/mappers/libmod_so.la', needed by `httpd'. Stop.
make: *** [all-recursive] Error 1
Reverting it fixes the problem.
Regards
Rüdiger
Re: svn commit: r771940 - in /httpd/httpd/trunk/modules/proxy: ./
balancers/ examples/
Posted by jean-frederic clere <jf...@gmail.com>.
Jim Jagielski wrote:
>
> On May 5, 2009, at 3:08 PM, Ruediger Pluem wrote:
>
>>> @@ -1471,13 +1471,13 @@
>>>
>>> PROXY_DECLARE(void)
>>> ap_proxy_add_worker_to_balancer(apr_pool_t *pool, proxy_balancer
>>> *balancer,
>>> - proxy_worker *worker)
>>> + proxy_worker **worker)
>>
>> IMHO providing *worker as the old code does is sufficient.
>>
>
> Plus, it cleans things up and keeps the PROXY_DECLARE such that
> we don't need to worry about an API bump
>
>>> {
>>> - proxy_worker *runtime;
>>> + proxy_worker **runtime;
>>>
>>> runtime = apr_array_push(balancer->workers);
>>> - memcpy(runtime, worker, sizeof(proxy_worker));
>>> - runtime->id = proxy_lb_workers;
>>> + memcpy(runtime, worker, sizeof(proxy_worker *));
>>
>> Do we really need memcpy here? Shouldn't
>>
>> *runtime = *worker
>>
>> be sufficient or in the case that we go back to the old
>> function prototype shouldn't
>>
>> *runtime = worker
>>
>> be enough?
>>
>
> +1
>
> I'm guessing jfc simply kept the code the same with no optimizations :)
>
I hurried to commit before you :-) - My bad: Sorry -
Cheers
Jean-Frederic
Re: svn commit: r771940 - in /httpd/httpd/trunk/modules/proxy: ./ balancers/ examples/
Posted by Jim Jagielski <ji...@apache.org>.
On May 5, 2009, at 3:08 PM, Ruediger Pluem wrote:
>> @@ -1471,13 +1471,13 @@
>>
>> PROXY_DECLARE(void)
>> ap_proxy_add_worker_to_balancer(apr_pool_t *pool, proxy_balancer
>> *balancer,
>> - proxy_worker *worker)
>> + proxy_worker **worker)
>
> IMHO providing *worker as the old code does is sufficient.
>
Plus, it cleans things up and keeps the PROXY_DECLARE such that
we don't need to worry about an API bump
>> {
>> - proxy_worker *runtime;
>> + proxy_worker **runtime;
>>
>> runtime = apr_array_push(balancer->workers);
>> - memcpy(runtime, worker, sizeof(proxy_worker));
>> - runtime->id = proxy_lb_workers;
>> + memcpy(runtime, worker, sizeof(proxy_worker *));
>
> Do we really need memcpy here? Shouldn't
>
> *runtime = *worker
>
> be sufficient or in the case that we go back to the old
> function prototype shouldn't
>
> *runtime = worker
>
> be enough?
>
+1
I'm guessing jfc simply kept the code the same with no optimizations :)