You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2003/05/14 08:17:17 UTC
Re: cvs commit: httpd-2.0 STATUS
--On Wednesday, May 14, 2003 5:17 AM +0000 aaron@apache.org wrote:
> aaron 2003/05/13 22:17:29
>
> Modified: . Tag: APACHE_2_0_BRANCH STATUS
> Log:
> Add a vote to commit the same patch I just committed to HEAD, so that
> --enable-mods-shared=most/all will start working again.
I think you committed to the branch not HEAD. =)
Though the patch looks right at first glance. Thought we had fixed this
problem a while back - I wonder what happened to regress. -- justin
Re: cvs commit: httpd-2.0 STATUS
Posted by Jeff Trawick <tr...@attglobal.net>.
Aaron Bannert wrote:
>
> On Wednesday, May 14, 2003, at 07:47 AM, Jeff Trawick wrote:
>
>> Jeff Trawick wrote:
>>
>>> So what I need to do now is test a change to configure.in to pick up
>>> the right AIX and BeOS with various configure invocations, commit to
>>> 2.1-dev, and submit again for merging into 2.0.46-dev.
>>
>>
>> Actually, all is well now, since when "static" is passed in enable_so
>> to APACHE_MODULE(), it gets reset to "yes" so that the configure.in
>> check will work.
>
>
> So everything is correct now and my changes didn't break AIX?
yes!
so yank the entry from STATUS and put the change in 2.1-dev
> At one point, "yes" started to mean "enable this module, and use the
> default {static or shared}".
> So --enable-foo would set mod_foo to "yes", and --eanble-foo=shared
> would set mod_foo to "shared",
> and so on. Does this jive with your understanding of the meaning?
basically...
--enable-foo sets the variable enable_foo=yes
--enable-foo=shared sets the variable enable_foo=shared
--disable-foo sets the variable enable_foo=no
Re: cvs commit: httpd-2.0 STATUS
Posted by Aaron Bannert <aa...@clove.org>.
On Wednesday, May 14, 2003, at 07:47 AM, Jeff Trawick wrote:
> Jeff Trawick wrote:
>
>> So what I need to do now is test a change to configure.in to pick up
>> the right AIX and BeOS with various configure invocations, commit to
>> 2.1-dev, and submit again for merging into 2.0.46-dev.
>
> Actually, all is well now, since when "static" is passed in enable_so
> to APACHE_MODULE(), it gets reset to "yes" so that the configure.in
> check will work.
So everything is correct now and my changes didn't break AIX?
At one point, "yes" started to mean "enable this module, and use the
default {static or shared}".
So --enable-foo would set mod_foo to "yes", and --eanble-foo=shared
would set mod_foo to "shared",
and so on. Does this jive with your understanding of the meaning?
-aaron
Re: cvs commit: httpd-2.0 STATUS
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick wrote:
> So what I need to do now is test a change to configure.in to pick up the
> right AIX and BeOS with various configure invocations, commit to
> 2.1-dev, and submit again for merging into 2.0.46-dev.
Actually, all is well now, since when "static" is passed in enable_so to
APACHE_MODULE(), it gets reset to "yes" so that the configure.in check
will work.
groan
Re: cvs commit: httpd-2.0 STATUS
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz wrote:
> Ah, Jeff's patch removed that specific check in r1.16, which he just
> backported this morning to 2.0. I'm not entirely clear what his patch
> was doing now that I look at it. I'm wondering if AIX needs mod_so as a
> shared object. How exactly does that work? So, I think we've got
> conflicting patches now.
>
> I think we need a closer look/explanation at Jeff's patch... -- justin
The main purpose of the patch was so that this ancient logic in
configure.in would be triggered:
if test "$enable_so" = "yes"; then
case $host in
*-ibm-aix*)
stuff
*beos)
stuff
*os390)
stuff
esac
fi
When mod_so defaulted to enabled, the enable_so variable was not set so
the test always failed. This somehow broke between 2.0.44 and 2.0.45.
Secondary reasons were
1) to have configure actually emit a message (e.g., "yes") after it
prints "checking whether to enable mod_so..."
2) to add another sanity check for configurations that didn't make sense
3) to use the APR macro for checking the APR_HAS_DSO feature instead of
doing an explicit compile (some cases in Apache where we did an explicit
compile didn't work with an out-of-tree APR build, though I don't think
this was one of those cases)
Alas, while I tried a number of testcases prior to committing to
2.1-dev, I did not try --enable-mods-shared=most :)
So what I need to do now is test a change to configure.in to pick up the
right AIX and BeOS with various configure invocations, commit to
2.1-dev, and submit again for merging into 2.0.46-dev.
Re: cvs commit: httpd-2.0 STATUS
Posted by Aaron Bannert <aa...@clove.org>.
On Tuesday, May 13, 2003, at 11:55 PM, Justin Erenkrantz wrote:
> --On Tuesday, May 13, 2003 11:45 PM -0700 Aaron Bannert
> <aa...@clove.org> wrote:
>
>> I comitted the vote to the 2.0 branch, but the fix to HEAD. Was
>> that incorrect?
>
> I'm only seeing the commit to modules/mappers/config9.m4 in 2.0 - not
> in HEAD. Wonder what happened.
Ah you're right, I must have checked out the repository incorrectly...
Hmm...vote to forward patch then? :)
>> (I thought I fixed it too, at least I remember fixing some part
>> of the --enable-mods-shared code awhile ago.)
>
> Ah, Jeff's patch removed that specific check in r1.16, which he just
> backported this morning to 2.0. I'm not entirely clear what his patch
> was doing now that I look at it. I'm wondering if AIX needs mod_so as
> a shared object. How exactly does that work? So, I think we've got
> conflicting patches now.
>
> I think we need a closer look/explanation at Jeff's patch... -- justin
Yeah, it wasn't clear to me what his patch did either. Though, I thought
AIX couldn't deal with DSOs that depended on other DSOs.
-aaron
Re: cvs commit: httpd-2.0 STATUS
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, May 13, 2003 11:45 PM -0700 Aaron Bannert <aa...@clove.org>
wrote:
> I comitted the vote to the 2.0 branch, but the fix to HEAD. Was
> that incorrect?
I'm only seeing the commit to modules/mappers/config9.m4 in 2.0 - not in HEAD.
Wonder what happened.
> (I thought I fixed it too, at least I remember fixing some part
> of the --enable-mods-shared code awhile ago.)
Ah, Jeff's patch removed that specific check in r1.16, which he just
backported this morning to 2.0. I'm not entirely clear what his patch was
doing now that I look at it. I'm wondering if AIX needs mod_so as a shared
object. How exactly does that work? So, I think we've got conflicting
patches now.
I think we need a closer look/explanation at Jeff's patch... -- justin
Re: cvs commit: httpd-2.0 STATUS
Posted by Aaron Bannert <aa...@clove.org>.
I comitted the vote to the 2.0 branch, but the fix to HEAD. Was
that incorrect?
(I thought I fixed it too, at least I remember fixing some part
of the --enable-mods-shared code awhile ago.)
-aaron
On Tuesday, May 13, 2003, at 11:17 PM, Justin Erenkrantz wrote:
> --On Wednesday, May 14, 2003 5:17 AM +0000 aaron@apache.org wrote:
>
>> aaron 2003/05/13 22:17:29
>>
>> Modified: . Tag: APACHE_2_0_BRANCH STATUS
>> Log:
>> Add a vote to commit the same patch I just committed to HEAD, so
>> that
>> --enable-mods-shared=most/all will start working again.
>
> I think you committed to the branch not HEAD. =)
>
> Though the patch looks right at first glance. Thought we had fixed
> this problem a while back - I wonder what happened to regress. --
> justin