You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/05/30 17:32:02 UTC
[PATCH] a bit of progress on the dso front
This is tiny progress in terms of code but big progress in terms of
whether or not the !@#$ing code will actually build out of the box.
Linux and Solaris (and I suspect OS/390) are happy now with no
makefile editing.
Any objections to committing this as-is?
Index: lib/apr/misc/unix/errorcodes.c
===================================================================
RCS file: /cvs/apache/apache-2.0/src/lib/apr/misc/unix/errorcodes.c,v
retrieving revision 1.18
diff -u -r1.18 errorcodes.c
--- errorcodes.c 2000/05/29 02:18:44 1.18
+++ errorcodes.c 2000/05/30 15:22:15
@@ -74,7 +74,9 @@
static char *apr_error_string(ap_status_t statcode)
{
+#if APR_HAS_DSO
char buf[256];
+#endif
switch (statcode) {
case APR_ENOPOOL:
return "A new pool could not be created.";
@@ -102,8 +104,10 @@
return "No thread key structure was provided and one was required.";
case APR_ENOSHMAVAIL:
return "No shared memory is currently available";
+#if APR_HAS_DSO
case APR_EDSOOPEN:
return ap_dso_error(buf, sizeof(buf), APR_EDSOOPEN);
+#endif
case APR_INCHILD:
return
"Your code just forked, and you are currently executing in the "
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] a bit of progress on the dso front
Posted by David Reid <dr...@jetnet.co.uk>.
Has anyone looked at the AIX DSO code yet? I'll look at the BeOS code later
today.
d.
----- Original Message -----
From: "Brian Havard" <br...@kheldar.apana.org.au>
To: <ne...@apache.org>
Sent: Wednesday, May 31, 2000 3:31 AM
Subject: Re: [PATCH] a bit of progress on the dso front
> On Tue, 30 May 2000 13:35:53 -0700 (PDT), Greg Stein wrote:
>
> >On Tue, 30 May 2000 rbb@covalent.net wrote:
> >> > > Ryan's given it a grudging +1. If you think it's ok too I'll commit
> >> > > it.
> >
> >+1 here, although I think some further tweaks are necessary. That can
> >happen in a second step.
>
> Ok, there it goes. Tweak away :)
>
> --
>
____________________________________________________________________________
__
> | Brian Havard | "He is not the messiah!
|
> | brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of
Brian |
> -------------------------------------------------------------------------
-----
>
>
Re: [PATCH] a bit of progress on the dso front
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Tue, 30 May 2000 13:35:53 -0700 (PDT), Greg Stein wrote:
>On Tue, 30 May 2000 rbb@covalent.net wrote:
>> > > Ryan's given it a grudging +1. If you think it's ok too I'll commit
>> > > it.
>
>+1 here, although I think some further tweaks are necessary. That can
>happen in a second step.
Ok, there it goes. Tweak away :)
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: [PATCH] a bit of progress on the dso front
Posted by rb...@covalent.net.
> > > > Ryan's given it a grudging +1. If you think it's ok too I'll commit
> > > > it.
>
> +1 here, although I think some further tweaks are necessary. That can
> happen in a second step.
>
> > > I thought it was later decided to go the APR_HAS_DSO route.
> >
> > Regardless of how we solve the error handling code, APR_HAS_DSO MUST be
> > added. The two options are not mutually exclusive. The APR_HAS_DSO
> > feature macro is what keeps us from compiling any DSO code. The error
> > handling needs to be correct for when we do have DSO compiled in.
>
> Agreed.
Quick note about this. I am going to put in the APR_HAS_DSO feature macro
probably tomorrow now. I was going to do it today, but I don't want to
step on Brian's patch, so I am waiting for him to commit his DSO error
handling before I tackle the next step.
So, if you don't see the APR_HAS_DSO today, just be patient, it's on the
way, but we have to go one step at a time. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] a bit of progress on the dso front
Posted by Greg Stein <gs...@lyra.org>.
On Tue, 30 May 2000 rbb@covalent.net wrote:
> > > Ryan's given it a grudging +1. If you think it's ok too I'll commit
> > > it.
+1 here, although I think some further tweaks are necessary. That can
happen in a second step.
> > I thought it was later decided to go the APR_HAS_DSO route.
>
> Regardless of how we solve the error handling code, APR_HAS_DSO MUST be
> added. The two options are not mutually exclusive. The APR_HAS_DSO
> feature macro is what keeps us from compiling any DSO code. The error
> handling needs to be correct for when we do have DSO compiled in.
Agreed.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] a bit of progress on the dso front
Posted by rb...@covalent.net.
> > Ryan's given it a grudging +1. If you think it's ok too I'll commit
> > it.
>
> I thought it was later decided to go the APR_HAS_DSO route.
Regardless of how we solve the error handling code, APR_HAS_DSO MUST be
added. The two options are not mutually exclusive. The APR_HAS_DSO
feature macro is what keeps us from compiling any DSO code. The error
handling needs to be correct for when we do have DSO compiled in.
Brian, please commit your patch soon so that I can add APR_HAS_DSO in all
the right places. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] a bit of progress on the dso front
Posted by Jeff Trawick <tr...@bellsouth.net>.
> From: "Brian Havard" <br...@kheldar.apana.org.au>
> Date: Wed, 31 May 2000 01:40:45 +1000 (EST)
>
> On Tue, 30 May 2000 11:32:02 -0400, Jeff Trawick wrote:
>
> >This is tiny progress in terms of code but big progress in terms of
> >whether or not the !@#$ing code will actually build out of the box.
> >Linux and Solaris (and I suspect OS/390) are happy now with no
> >makefile editing.
> >
> >Any objections to committing this as-is?
>
> Yes, it conflicts with my patch to this same area. I think what I've done
> also fixes the problem you're trying to solve here. See Message-Id
> <20...@silk.apana.org.au>
>
> Ryan's given it a grudging +1. If you think it's ok too I'll commit
> it.
I thought it was later decided to go the APR_HAS_DSO route.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] a bit of progress on the dso front
Posted by rb...@covalent.net.
> >This is tiny progress in terms of code but big progress in terms of
> >whether or not the !@#$ing code will actually build out of the box.
> >Linux and Solaris (and I suspect OS/390) are happy now with no
> >makefile editing.
> >
> >Any objections to committing this as-is?
>
> Yes, it conflicts with my patch to this same area. I think what I've done
> also fixes the problem you're trying to solve here. See Message-Id
> <20...@silk.apana.org.au>
>
> Ryan's given it a grudging +1. If you think it's ok too I'll commit it.
I much prefer Brian's patch to this one BTW.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] a bit of progress on the dso front
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Tue, 30 May 2000 11:32:02 -0400, Jeff Trawick wrote:
>This is tiny progress in terms of code but big progress in terms of
>whether or not the !@#$ing code will actually build out of the box.
>Linux and Solaris (and I suspect OS/390) are happy now with no
>makefile editing.
>
>Any objections to committing this as-is?
Yes, it conflicts with my patch to this same area. I think what I've done
also fixes the problem you're trying to solve here. See Message-Id
<20...@silk.apana.org.au>
Ryan's given it a grudging +1. If you think it's ok too I'll commit it.
>Index: lib/apr/misc/unix/errorcodes.c
>===================================================================
>RCS file: /cvs/apache/apache-2.0/src/lib/apr/misc/unix/errorcodes.c,v
>retrieving revision 1.18
>diff -u -r1.18 errorcodes.c
>--- errorcodes.c 2000/05/29 02:18:44 1.18
>+++ errorcodes.c 2000/05/30 15:22:15
>@@ -74,7 +74,9 @@
>
> static char *apr_error_string(ap_status_t statcode)
> {
>+#if APR_HAS_DSO
> char buf[256];
>+#endif
> switch (statcode) {
> case APR_ENOPOOL:
> return "A new pool could not be created.";
>@@ -102,8 +104,10 @@
> return "No thread key structure was provided and one was required.";
> case APR_ENOSHMAVAIL:
> return "No shared memory is currently available";
>+#if APR_HAS_DSO
> case APR_EDSOOPEN:
> return ap_dso_error(buf, sizeof(buf), APR_EDSOOPEN);
>+#endif
> case APR_INCHILD:
> return
> "Your code just forked, and you are currently executing in the "
>
>
>--
>Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: [PATCH] a bit of progress on the dso front
Posted by Jeff Trawick <tr...@bellsouth.net>.
> From: rbb@covalent.net
> X-Authentication-Warning: koj.rkbloom.net: rbb owned process doing -bs
> Date: Tue, 30 May 2000 08:36:23 -0700 (PDT)
> X-Sender: rbb@koj.rkbloom.net
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> X-UIDL: fe02a7e164947275f8990f5cc649e505
>
>
> APR_HAS_DSO isn't actually defined anywhere that I can see. This works by
> breaking things. Not good, IMHO.
>
> Ryan
>
It certainly isn't defined. The only thing that breaks is getting the
right error string for a DSO error. What it fixes is being able to
build Apache statically without editing makefiles. IMHO, that is much
more important. Being able to get the right error string for a DSO
error will work again when somebody gets around to defining APR_HAS_DSO
properly.
(Yestderday, on Linux I tried make distclean followed by a
"--enable-shared" build to see if everything would build cleanly, but
I got some error which I can no longer remember (some problem at link
time with something in a .libs directory). With the understanding
that --enable-shared isn't building right either, I don't have a any
qualms about temporarily disabling the ability to get the right error
string in return for being able to build statically. If
--enable-shared is working great everywhere and we're getting great
strings from ap_dso_error(), then the situation is different than how
I see it.)
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] a bit of progress on the dso front
Posted by rb...@covalent.net.
APR_HAS_DSO isn't actually defined anywhere that I can see. This works by
breaking things. Not good, IMHO.
Ryan
On Tue, 30 May 2000, Jeff Trawick wrote:
> This is tiny progress in terms of code but big progress in terms of
> whether or not the !@#$ing code will actually build out of the box.
> Linux and Solaris (and I suspect OS/390) are happy now with no
> makefile editing.
>
> Any objections to committing this as-is?
>
> Index: lib/apr/misc/unix/errorcodes.c
> ===================================================================
> RCS file: /cvs/apache/apache-2.0/src/lib/apr/misc/unix/errorcodes.c,v
> retrieving revision 1.18
> diff -u -r1.18 errorcodes.c
> --- errorcodes.c 2000/05/29 02:18:44 1.18
> +++ errorcodes.c 2000/05/30 15:22:15
> @@ -74,7 +74,9 @@
>
> static char *apr_error_string(ap_status_t statcode)
> {
> +#if APR_HAS_DSO
> char buf[256];
> +#endif
> switch (statcode) {
> case APR_ENOPOOL:
> return "A new pool could not be created.";
> @@ -102,8 +104,10 @@
> return "No thread key structure was provided and one was required.";
> case APR_ENOSHMAVAIL:
> return "No shared memory is currently available";
> +#if APR_HAS_DSO
> case APR_EDSOOPEN:
> return ap_dso_error(buf, sizeof(buf), APR_EDSOOPEN);
> +#endif
> case APR_INCHILD:
> return
> "Your code just forked, and you are currently executing in the "
>
>
> --
> Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] a bit of progress on the dso front
Posted by rb...@covalent.net.
I'll add support for APR_HAS_DSO later today. This will allow Apache to
build properly when I am done.
Ryan
On Tue, 30 May 2000, Jeff Trawick wrote:
> > From: "William A. Rowe, Jr." <wr...@lnd.com>
> >
> > Yes - add the APR_HAS_DSO to the config (NOT to Win32 :-) before
> > you commit
> >
>
> If I knew exactly what to do there and had time to do it, I would have
> done it already :) I was looking for forward progress towards the
> final goal.
>
> I won't pretend to have the complete summary of all the messages on
> the topic from yesterday, but I do remember that
>
> 1) APR configuration needs to be told by Apache whether or not to try
> to add dso support and define APR_HAS_DSO to 0 or 1 as appropriate.
> (This may or may not be influenced by whether or not APR can
> actually implement dso support on the target platform.)
>
> For apr.hw, "#define APR_HAS_DSO 0" if the dso stuff doesn't map
> to Win32 dlls.
>
> 2) "#if APR_HAS_DSO" needs to be placed around code that uses the DSO
> support
>
>
>
> > > -----Original Message-----
> > > From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> > > Sent: Tuesday, May 30, 2000 10:32 AM
> > > To: new-httpd@apache.org
> > > Subject: [PATCH] a bit of progress on the dso front
> > >
> > >
> > > This is tiny progress in terms of code but big progress in terms of
> > > whether or not the !@#$ing code will actually build out of the box.
> > > Linux and Solaris (and I suspect OS/390) are happy now with no
> > > makefile editing.
> > >
> > > Any objections to committing this as-is?
> > >
> > > Index: lib/apr/misc/unix/errorcodes.c
> > > ===================================================================
> > > RCS file: /cvs/apache/apache-2.0/src/lib/apr/misc/unix/errorcodes.c,v
> > > retrieving revision 1.18
> > > diff -u -r1.18 errorcodes.c
> > > --- errorcodes.c 2000/05/29 02:18:44 1.18
> > > +++ errorcodes.c 2000/05/30 15:22:15
> > > @@ -74,7 +74,9 @@
> > >
> > > static char *apr_error_string(ap_status_t statcode)
> > > {
> > > +#if APR_HAS_DSO
> > > char buf[256];
> > > +#endif
> > > switch (statcode) {
> > > case APR_ENOPOOL:
> > > return "A new pool could not be created.";
> > > @@ -102,8 +104,10 @@
> > > return "No thread key structure was provided and one
> > > was required.";
> > > case APR_ENOSHMAVAIL:
> > > return "No shared memory is currently available";
> > > +#if APR_HAS_DSO
> > > case APR_EDSOOPEN:
> > > return ap_dso_error(buf, sizeof(buf), APR_EDSOOPEN);
> > > +#endif
> > > case APR_INCHILD:
> > > return
> > > "Your code just forked, and you are currently
> > > executing in the "
> > >
> > >
> > > --
> > > Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> > > http://www.geocities.com/SiliconValley/Park/9289/
> > > Born in Roswell... married an alien...
> > >
> >
>
>
> --
> Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] a bit of progress on the dso front
Posted by Jeff Trawick <tr...@bellsouth.net>.
> From: "William A. Rowe, Jr." <wr...@lnd.com>
>
> Yes - add the APR_HAS_DSO to the config (NOT to Win32 :-) before
> you commit
>
If I knew exactly what to do there and had time to do it, I would have
done it already :) I was looking for forward progress towards the
final goal.
I won't pretend to have the complete summary of all the messages on
the topic from yesterday, but I do remember that
1) APR configuration needs to be told by Apache whether or not to try
to add dso support and define APR_HAS_DSO to 0 or 1 as appropriate.
(This may or may not be influenced by whether or not APR can
actually implement dso support on the target platform.)
For apr.hw, "#define APR_HAS_DSO 0" if the dso stuff doesn't map
to Win32 dlls.
2) "#if APR_HAS_DSO" needs to be placed around code that uses the DSO
support
> > -----Original Message-----
> > From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> > Sent: Tuesday, May 30, 2000 10:32 AM
> > To: new-httpd@apache.org
> > Subject: [PATCH] a bit of progress on the dso front
> >
> >
> > This is tiny progress in terms of code but big progress in terms of
> > whether or not the !@#$ing code will actually build out of the box.
> > Linux and Solaris (and I suspect OS/390) are happy now with no
> > makefile editing.
> >
> > Any objections to committing this as-is?
> >
> > Index: lib/apr/misc/unix/errorcodes.c
> > ===================================================================
> > RCS file: /cvs/apache/apache-2.0/src/lib/apr/misc/unix/errorcodes.c,v
> > retrieving revision 1.18
> > diff -u -r1.18 errorcodes.c
> > --- errorcodes.c 2000/05/29 02:18:44 1.18
> > +++ errorcodes.c 2000/05/30 15:22:15
> > @@ -74,7 +74,9 @@
> >
> > static char *apr_error_string(ap_status_t statcode)
> > {
> > +#if APR_HAS_DSO
> > char buf[256];
> > +#endif
> > switch (statcode) {
> > case APR_ENOPOOL:
> > return "A new pool could not be created.";
> > @@ -102,8 +104,10 @@
> > return "No thread key structure was provided and one
> > was required.";
> > case APR_ENOSHMAVAIL:
> > return "No shared memory is currently available";
> > +#if APR_HAS_DSO
> > case APR_EDSOOPEN:
> > return ap_dso_error(buf, sizeof(buf), APR_EDSOOPEN);
> > +#endif
> > case APR_INCHILD:
> > return
> > "Your code just forked, and you are currently
> > executing in the "
> >
> >
> > --
> > Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> > http://www.geocities.com/SiliconValley/Park/9289/
> > Born in Roswell... married an alien...
> >
>
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
RE: [PATCH] a bit of progress on the dso front
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Yes - add the APR_HAS_DSO to the config (NOT to Win32 :-) before
you commit
> -----Original Message-----
> From: Jeff Trawick [mailto:trawickj@bellsouth.net]
> Sent: Tuesday, May 30, 2000 10:32 AM
> To: new-httpd@apache.org
> Subject: [PATCH] a bit of progress on the dso front
>
>
> This is tiny progress in terms of code but big progress in terms of
> whether or not the !@#$ing code will actually build out of the box.
> Linux and Solaris (and I suspect OS/390) are happy now with no
> makefile editing.
>
> Any objections to committing this as-is?
>
> Index: lib/apr/misc/unix/errorcodes.c
> ===================================================================
> RCS file: /cvs/apache/apache-2.0/src/lib/apr/misc/unix/errorcodes.c,v
> retrieving revision 1.18
> diff -u -r1.18 errorcodes.c
> --- errorcodes.c 2000/05/29 02:18:44 1.18
> +++ errorcodes.c 2000/05/30 15:22:15
> @@ -74,7 +74,9 @@
>
> static char *apr_error_string(ap_status_t statcode)
> {
> +#if APR_HAS_DSO
> char buf[256];
> +#endif
> switch (statcode) {
> case APR_ENOPOOL:
> return "A new pool could not be created.";
> @@ -102,8 +104,10 @@
> return "No thread key structure was provided and one
> was required.";
> case APR_ENOSHMAVAIL:
> return "No shared memory is currently available";
> +#if APR_HAS_DSO
> case APR_EDSOOPEN:
> return ap_dso_error(buf, sizeof(buf), APR_EDSOOPEN);
> +#endif
> case APR_INCHILD:
> return
> "Your code just forked, and you are currently
> executing in the "
>
>
> --
> Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>