Re: I'd like to release 1.3.24...
>Here's a patch to bail out on ./Configure errors. Sorry about the >&3 >redirection, but without it, we would have to create an intermediate >file (and need to prevent race conditions, need to clean up & all that). Let me see look into this... I think there's a clearer way... >Also, I added a 2>&1 redirection to Configure's sanity check report >(without it, the "echo ===" output will not always be where the >error output is). > >Should I commit? +1 on this part -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
[PATCH] Re: I'd like to release 1.3.24...
On Mon, Feb 04, 2002 at 01:58:25PM +0100, Kraemer, Martin wrote: > Here's a patch to bail out on ./Configure errors. Sorry about the >&3 > redirection, but without it, we would have to create an intermediate > file (and need to prevent race conditions, need to clean up & all that). Only I forgot to add [PATCH] to the subject line. For the patch, see the previous mail. Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: I'd like to release 1.3.24...
Here's a patch to bail out on ./Configure errors. Sorry about the >&3
redirection, but without it, we would have to create an intermediate
file (and need to prevent race conditions, need to clean up & all that).
Also, I added a 2>&1 redirection to Configure's sanity check report
(without it, the "echo ===" output will not always be where the
error output is).
Should I commit?
Martin
--
<[EMAIL PROTECTED]> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Index: configure
===
RCS file: /home/cvs/apache-1.3/configure,v
retrieving revision 1.133
diff -u -r1.133 configure
--- configure 27 Sep 2001 18:12:03 - 1.133
+++ configure 4 Feb 2002 12:54:24 -
@@ -1582,14 +1582,15 @@
if [ "x$verbose" = "xyes" ]; then
vflag="-v";
fi
-if [ "x$quiet" = "xyes" ]; then
-(cd $src; ./Configure ${vflag} -file Configuration.apaci >/dev/null);
+rc=`if [ "x$quiet" = "xyes" ]; then
+(cd $src; ./Configure ${vflag} -file Configuration.apaci >/dev/null; echo $? >&3;
+);
else
-(cd $src; ./Configure ${vflag} -file Configuration.apaci |\
+(cd $src; ( ./Configure ${vflag} -file Configuration.apaci; echo $? >&3; ) |\
sed -e '/^Using config file:.*/d' \
-e "s:Makefile in :Makefile in $src\\/:" \
-e "s:Makefile\$:Makefile in $src:")
-fi
+fi 3>&1 1>&2`
+[ $rc = 0 ] || exit 1
##
## final hints
Index: src/Configure
===
RCS file: /home/cvs/apache-1.3/src/Configure,v
retrieving revision 1.449
diff -u -r1.449 Configure
--- src/Configure 1 Feb 2002 02:27:04 - 1.449
+++ src/Configure 4 Feb 2002 12:54:25 -
@@ -2398,7 +2398,7 @@
echo "** Apache requires an ANSI C Compiler, such as gcc. "
echo ""
echo " Error Output for sanity check "
- (./helpers/TestCompile -v sanity)
+ (./helpers/TestCompile -v sanity) 2>&1
echo "= End of Error Report ="
echo ""
echo " Aborting!"
Re: I'd like to release 1.3.24...
On Sat, Feb 02, 2002 at 04:34:14PM -0500, Rodent of Unusual Size wrote:
>
> if [ "x$quiet" = "xyes" ]; then
> (cd $src; \
> ./Configure ${vflag} -file Configuration.apaci >/dev/null || \
> exit $?);
> else
Nope -- this will do the same as it did: terminate the subshell
with an error (which is ignored).
You could do...
if [ "x$quiet" = "xyes" ]; then
(cd $src; ./Configure ${vflag} -file Configuration.apaci >/dev/null) || exit;
-either-
else
(cd $src; ./Configure ${vflag} -file Configuration.apaci |\
sed -e '/^Using config file:.*/d' \
-e "s:Makefile in :Makefile in $src\\/:" \
-e "s:Makefile\$:Makefile in $src:")
fi || exit
or-^^^
But the "else" branch is more tricky, as you said.
Martin
--
<[EMAIL PROTECTED]> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: I'd like to release 1.3.24...
Rodent of Unusual Size wrote:
>
>
> if [ "x$quiet" = "xyes" ]; then
> (cd $src; \
> ./Configure ${vflag} -file Configuration.apaci >/dev/null || \
> exit $?);
The exit $? *inside* the subshell is redundant. As mentioned in my previous
email (you may not have seen it yet) the error code of the completed
subshell is available as $?. eg:
(cd src; ./Configure );
echo $?
prints out the exit code of the complete subshell.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
Re: I'd like to release 1.3.24...
Jeff Trawick wrote:
>
> By the way... would a shell expert such as yourself know how
> to catch a bad exit from apache-1.3/src/Configure in the
> apache-1.3/configure code below and make sure that configure
> exits with a bad status too?
>
> if [ "x$quiet" = "xyes" ]; then
> (cd $src; ./Configure ${vflag} -file Configuration.apaci >/dev/null);
> else
> (cd $src; ./Configure ${vflag} -file Configuration.apaci |\
> sed -e '/^Using config file:.*/d' \
> -e "s:Makefile in :Makefile in $src\\/:" \
> -e "s:Makefile\$:Makefile in $src:")
> fi
Maybe this for the 'then' clause:
if [ "x$quiet" = "xyes" ]; then
(cd $src; \
./Configure ${vflag} -file Configuration.apaci >/dev/null || \
exit $?);
else
The else clause is rather more difficult.. :-/
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
Re: I'd like to release 1.3.24...
Jeff Trawick wrote:
>
>
> By the way... would a shell expert such as yourself know how to catch
> a bad exit from apache-1.3/src/Configure in the apache-1.3/configure
> code below and make sure that configure exits with a bad status too?
>
> if [ "x$quiet" = "xyes" ]; then
> (cd $src; ./Configure ${vflag} -file Configuration.apaci >/dev/null);
At this point, the error code from the sub-shell is available as $?
so you could use that result to expand your conditionals. So you
could check if $? was 0 and if not, exit $? to pop that error code
up to the next shell level (which would be the error code returned
by Configure)
> else
> (cd $src; ./Configure ${vflag} -file Configuration.apaci |\
> sed -e '/^Using config file:.*/d' \
> -e "s:Makefile in :Makefile in $src\\/:" \
> -e "s:Makefile\$:Makefile in $src:")
> fi
>
> Use case:
>
> Some dumbass like me sets CFLAGS to something bogus and runs
> configure... the bad CFLAGS causes the compiler sanity check to fail
> but configure exits with status 0 and a script that does the configure
> will keep on trucking until the build fails at a more confusing place.
>
> --
> Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
>http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
Re: I'd like to release 1.3.24...
Dale Ghent wrote: > > On Sat, 2 Feb 2002, Jim Jagielski wrote: > > | I'd like for us to consider releasing 1.3.24 specifically for the Solaris > | pthread fix. I offer to be RM. I'll update STATUS for voting and comments. > > I don't know, I think it might be premature to do that. > > I still think that it's a bad idea to unconditionally include libpthread > on Solaris builds in cases where HPSA is not enabled, which would be > (relatively) rare situations because HPSA is not the default for Solaris. But it *is*. That's the point. Right now, 1.3.23 is broken for Solaris. And Solaris is an important enough and popular enough OS that it warrants something like this. > > Also, I think that since 1.3.9, the 1.3 tree has suffered from enough > "oops" releases to warrant maybe acumulating a few more fixes, then > testing, and then releasing. I do believe time is on our side for this > one and shouldnt be rushed so soon in the wake of .23. > Why? If we have a fix, then let's release it. Considering that the bug means that Solaris is broken "out of the box" is Not Good, in my opinion :) Fast turnaround is one of the advantages of open source and how we work... I'd prefer being slammed because we had 2 releases "close to each other" than having code out there that's not right, and we *know* it's not right. If we had the concept of patch level with our releases then it would be different. Yes, we could just release a patch, and we should do that anyway, but if the whole reason why we should release 1.3.24 is because we "just" released 1.3.23, I don't think that's strong enough. I don't mind putting forth the effort to release .24, and saying that unless you're running Solaris there's no compelling reason to upgrade... Just my opinion :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: I'd like to release 1.3.24...
Dale Ghent <[EMAIL PROTECTED]> writes: > My issue with including libpthread on Solaris builds that do not use > HAVE_PTHREAD_SERIALIZED_ACCEPT is that, as stated by the Sun docs at the > URL I posted yesterday, that unnecessary overhead is introduced into the > proces as thread-related structures and environment is set up and > maintained for the process... which is then never utilized. There are no Solaris builds without HAVE_PTHREAD_SERIALIZED_ACCEPT since before 1.3.21. > It seems like a performance hit we can avoid. We can stick -lpthread in > LIBS and then enable HAVE_PTHREAD_SERIALIZED_ACCEPT for the default. 1.3.23 has HPAS (I should let you catch up with your mail :) over-and-out for now) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: I'd like to release 1.3.24...
Dale Ghent wrote: > > Attached is a patch to add -DUSE_PTHREAD_SERIALIZED_ACCEPT to CFLAGS for > Solaris. > Not needed. The 1.3.23 code *as is* makes pthread the default for Solaris. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: I'd like to release 1.3.24...
Dale Ghent wrote: > > > My issue with including libpthread on Solaris builds that do not use > HAVE_PTHREAD_SERIALIZED_ACCEPT is that, as stated by the Sun docs at the > URL I posted yesterday, that unnecessary overhead is introduced into the > proces as thread-related structures and environment is set up and > maintained for the process... which is then never utilized. > > It seems like a performance hit we can avoid. We can stick -lpthread in > LIBS and then enable HAVE_PTHREAD_SERIALIZED_ACCEPT for the default. > Otherwise, having -lpthread in there and NOT using > HAVE_PTHREAD_SERIALIZED_ACCEPT would just be a performance handicap for > 90% of Solaris builds out there that do not enable > HAVE_PTHREAD_SERIALIZED_ACCEPT by hand. > Because we have HPSA added in ap_config.h for Solaris, it *is* enabled by default (we allow pthread, sysvsem and fcntl). The actual mutex method is runtime configurable, but if we want to allow pthread as one of the options, we *have* to compile against lpthread. By initial thought was have Configure smart enough to do a test compile under Solaris and see if HPSA is defined, and if so, add in in pthread lib. But after thinking it over, if someone is smart enough to want to totally disable even the prospect of using pthread mutex on Solaris, and edit ap_config.h to remove that, then they should also be smart enough to notice that lpthread needs to be removed as well. Maybe we should do this anyway, "just in case" but I don't think it's a show stopper... heck, some minor comments in the docs and code would be enough. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: I'd like to release 1.3.24...
On 2 Feb 2002, Jeff Trawick wrote: | what the heck is HPSA? | | I thought you wanted pthread mutex to be the default on Solaris and | not just a choice (like it is now)? Was that somebody else? HPSA Is my way of saying HAVE_PTHREAD_SERIALIZED_ACCEPT without having to type out that long dang string ;) Yeah, it was me saying that would be a good idea to make it the default. | In general I'm cool with slowing down on this, but first I'd like to | understand more about your concern with HPSA. The code is completely | busted as-is. Some people have ineffective accept serialization, | others have catastrophic failure, but certainly most people are | unaffected. My issue with including libpthread on Solaris builds that do not use HAVE_PTHREAD_SERIALIZED_ACCEPT is that, as stated by the Sun docs at the URL I posted yesterday, that unnecessary overhead is introduced into the proces as thread-related structures and environment is set up and maintained for the process... which is then never utilized. It seems like a performance hit we can avoid. We can stick -lpthread in LIBS and then enable HAVE_PTHREAD_SERIALIZED_ACCEPT for the default. Otherwise, having -lpthread in there and NOT using HAVE_PTHREAD_SERIALIZED_ACCEPT would just be a performance handicap for 90% of Solaris builds out there that do not enable HAVE_PTHREAD_SERIALIZED_ACCEPT by hand. | I hope to have a 2.7 test report in the next few days (a situation | where someone is hurting now and will have their httpd replaced with | one that pulls in -lpthread). Cool! /dale
Re: I'd like to release 1.3.24...
Dale Ghent <[EMAIL PROTECTED]> writes: > On Sat, 2 Feb 2002, Dale Ghent wrote: > > | I still think that it's a bad idea to unconditionally include libpthread > | on Solaris builds in cases where HPSA is not enabled, which would be > | (relatively) rare situations because HPSA is not the default for Solaris. > > Replying to my own email here. > > I figured, that since we're halfway there by adding -lpthread to LIBS, we > might as well go all-out and make it useful to us on Solaris. No, we're all the way there. We turn on HAVE_PTHREAD_SERIALIZED_ACCEPT in ap_config.h and add -lpthread in src/Configure. We were half-way there in 1.3.23 where we turned on HAVE_PTHREAD_SERIALIZED_ACCEPT in ap_config.h but didn't add -lpthread in src/Configure. > Attached is a patch to add -DUSE_PTHREAD_SERIALIZED_ACCEPT to CFLAGS for > Solaris. Now its my turn to be conservative and wonder why you want to change the *default* mutex serialization now :) > I've tested HPSA sucessfully on Solaris 8, and recently, with 2.6. Both > had expected results and no unexpected side-effects. I finally figured out what you meant by HPSA -- HAVE_PTHREAD_SERIALIZED_ACCEPT. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: I'd like to release 1.3.24...
Dale Ghent <[EMAIL PROTECTED]> writes: > On Sat, 2 Feb 2002, Jim Jagielski wrote: > > | I'd like for us to consider releasing 1.3.24 specifically for the Solaris > | pthread fix. I offer to be RM. I'll update STATUS for voting and comments. > > I don't know, I think it might be premature to do that. > > I still think that it's a bad idea to unconditionally include libpthread > on Solaris builds in cases where HPSA is not enabled, which would be > (relatively) rare situations because HPSA is not the default for Solaris. what the heck is HPSA? I thought you wanted pthread mutex to be the default on Solaris and not just a choice (like it is now)? Was that somebody else? > The effects of this should at least be tested first, before releasing to > the general populace. I vollunteer to do this on Solaris 8. > Unfortuanately, I just ditched my only 2.6 box, so testing the effects on > there would have to be done by someone else. In general I'm cool with slowing down on this, but first I'd like to understand more about your concern with HPSA. The code is completely busted as-is. Some people have ineffective accept serialization, others have catastrophic failure, but certainly most people are unaffected. I hope to have a 2.7 test report in the next few days (a situation where someone is hurting now and will have their httpd replaced with one that pulls in -lpthread). -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: I'd like to release 1.3.24...
On Sat, 2 Feb 2002, Dale Ghent wrote: | I still think that it's a bad idea to unconditionally include libpthread | on Solaris builds in cases where HPSA is not enabled, which would be | (relatively) rare situations because HPSA is not the default for Solaris. Replying to my own email here. I figured, that since we're halfway there by adding -lpthread to LIBS, we might as well go all-out and make it useful to us on Solaris. Attached is a patch to add -DUSE_PTHREAD_SERIALIZED_ACCEPT to CFLAGS for Solaris. I've tested HPSA sucessfully on Solaris 8, and recently, with 2.6. Both had expected results and no unexpected side-effects. /dale --- /local/src/apache-dev/apache-1.3/src/Configure.orig Sat Feb 2 14:23:05 2002 +++ /local/src/apache-dev/apache-1.3/src/Configure Sat Feb 2 14:23:31 2002 @@ -585,7 +585,7 @@ *-solaris2*) PLATOSVERS=`echo $PLAT | sed 's/^.*solaris2.//'` OS="Solaris $PLATOSVERS" - CFLAGS="$CFLAGS -DSOLARIS2=$PLATOSVERS" + CFLAGS="$CFLAGS -DSOLARIS2=$PLATOSVERS" -DUSE_PTHREAD_SERIALIZED_ACCEPT LIBS="$LIBS -lsocket -lnsl -lpthread" DBM_LIB="" case "$PLATOSVERS" in
Re: I'd like to release 1.3.24...
On Sat, 2 Feb 2002, Jim Jagielski wrote: | I'd like for us to consider releasing 1.3.24 specifically for the Solaris | pthread fix. I offer to be RM. I'll update STATUS for voting and comments. I don't know, I think it might be premature to do that. I still think that it's a bad idea to unconditionally include libpthread on Solaris builds in cases where HPSA is not enabled, which would be (relatively) rare situations because HPSA is not the default for Solaris. The effects of this should at least be tested first, before releasing to the general populace. I vollunteer to do this on Solaris 8. Unfortuanately, I just ditched my only 2.6 box, so testing the effects on there would have to be done by someone else. Also, I think that since 1.3.9, the 1.3 tree has suffered from enough "oops" releases to warrant maybe acumulating a few more fixes, then testing, and then releasing. I do believe time is on our side for this one and shouldnt be rushed so soon in the wake of .23. imho, /dale
Re: I'd like to release 1.3.24...
> Jim Jagielski <[EMAIL PROTECTED]> writes: > > > I'd like for us to consider releasing 1.3.24 specifically for the Solaris > > pthread fix. I offer to be RM. I'll update STATUS for voting and comments. > > +1 from me :( +1 Bill
Re: I'd like to release 1.3.24...
Jim Jagielski <[EMAIL PROTECTED]> writes:
> I'd like for us to consider releasing 1.3.24 specifically for the Solaris
> pthread fix. I offer to be RM. I'll update STATUS for voting and comments.
+1 from me :(
By the way... would a shell expert such as yourself know how to catch
a bad exit from apache-1.3/src/Configure in the apache-1.3/configure
code below and make sure that configure exits with a bad status too?
if [ "x$quiet" = "xyes" ]; then
(cd $src; ./Configure ${vflag} -file Configuration.apaci >/dev/null);
else
(cd $src; ./Configure ${vflag} -file Configuration.apaci |\
sed -e '/^Using config file:.*/d' \
-e "s:Makefile in :Makefile in $src\\/:" \
-e "s:Makefile\$:Makefile in $src:")
fi
Use case:
Some dumbass like me sets CFLAGS to something bogus and runs
configure... the bad CFLAGS causes the compiler sanity check to fail
but configure exits with status 0 and a script that does the configure
will keep on trucking until the build fails at a more confusing place.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
