On Sun, Mar 30, 2003 at 03:35:24AM +0200, Graham Leggett wrote:
Hi all,
(fudging config.m4 to remove mod_auth-digest that refuses to compile)
When I try to configure the latest head of v2.0 with the following line,
it bombs out further down with an error:
./configure
Okay, The last message was premature (typical for a newbie). And sorry for
the annoying questions...
I've stepped through more of the startup code and found that the service is
getting started and then
if (!strcasecmp(signal_arg, start)) {
ap_listen_rec *lr;
/* Close the
Joe Orton wrote:
./configure --enable-mods-shared=all
checking whether to enable mod_userdir... shared (all)
checking whether to enable mod_alias... shared (all)
checking whether to enable mod_rewrite... shared (all)
configure: error: shared objects have been requested but cannot be built
Jeff Trawick wrote:
Can you try with some well-used autoconf instead of GNU Autoconf 2.57
and see if whatever is happening is related to the autoconf version?
I checked out a fresh copy of the source tree (as opposed to cvs
update'ing my existing tree) and the problems have gone away. I think
William A. Rowe, Jr. wrote:
At 08:07 PM 3/29/2003, Jeff Trawick wrote:
Maybe there is a Solaris patch for this :) It seems really sucky for exec to have a failure point after close-for-exec files are closed and after signal handling is reset.
No... look at what we do in apr_proc_child_create
Hi all,
The attached patch allows the http_roll_release script to be used to
pull releases out of tags other than just APACHE_2_0*, for example
WROWE_2_0_45_RC2.
Any thoughts?
Regards,
Graham
--
-
[EMAIL PROTECTED] There's a moon
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
From: Graham Leggett [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 30, 2003 3:42 PM
Hi all,
The attached patch allows the http_roll_release script to be used to
pull releases out of tags other than just APACHE_2_0*, for example
WROWE_2_0_45_RC2.
Any thoughts?
Yeah, http_roll_release
somebody tell me why I shouldn't commit this :)
Index: server/util.c
===
RCS file: /home/cvs/httpd-2.0/server/util.c,v
retrieving revision 1.133.2.2
diff -u -r1.133.2.2 util.c
--- server/util.c 12 Feb 2003 17:17:31 -
On Sun, 2003-03-30 at 08:47, Jeff Trawick wrote:
somebody tell me why I shouldn't commit this :)
Looks safe to me
Brian
I'm not seeing any close(-1) calls on a trace of a mod_cgid-invoked
script anymore now.
old trace (in the new script child prior to exec):
5108: close(4)= 0
5108: close(3)= 0
5108: close(-1)
--On Friday, March 28, 2003 10:30 AM -0800 Rasmus Lerdorf [EMAIL PROTECTED]
wrote:
In doing a bit of performance tweaking on 1.3, I noticed that
ap_send_header_field() does an ap_rvputs() with each little piece of a
header which results in separate ap_bwrite() calls for Primitive, :,
Value, crlf
On Sun, Mar 30, 2003 at 06:57:35PM -, Graham Leggett wrote:
...
--- buildconf 12 Mar 2003 01:30:05 - 1.32
+++ buildconf 30 Mar 2003 18:57:34 - 1.33
@@ -181,4 +181,19 @@
rm -f config.cache
${AUTOCONF:-autoconf} 21 | grep -v $cross_compile_warning
Joe Orton wrote:
+( VMMN=`echo MODULE_MAGIC_NUMBER_MAJOR | cpp -include \`pwd\`/include/ap_mmn.h |
grep -e '^[0-9]'`
+ REVISION=`echo AP_SERVER_MAJORVERSION.AP_SERVER_MINORVERSION.AP_SERVER_PATCHLEVEL | cpp -include
\`pwd\`/include/ap_release.h | tr -d \ | grep -e '^[0-9.\-]'`
I wouldn't
+1
Jeff Trawick wrote:
I'm not seeing any close(-1) calls on a trace of a mod_cgid-invoked
script anymore now.
old trace (in the new script child prior to exec):
5108: close(4)= 0
5108: close(3)= 0
5108:
--On Sunday, March 30, 2003 7:02 PM + [EMAIL PROTECTED] wrote:
Backport of the RPM build scripts to v2.0
Obtained from: Joe Orton [EMAIL PROTECTED]
This generates failures on Solaris (which does not have cpp). It also looks
like your grep usage is relying upon some extended grep
Justin Erenkrantz wrote:
This generates failures on Solaris (which does not have cpp). It also
looks
like your grep usage is relying upon some extended grep semantics (-e).
I will take the code out of buildconf until it can be fixed. I was not
aware of these portability issues, having used the
++1 - makes perfect sense.
One more oddball observation. Why repeatedly invoke the cleanups?
We need only a few handles in cgid, it seems that setting those few
handles aside and invoking cleanup_for_exec ourselves before we enter
the server loop in the fork()ed cgid worker would speed things
--On Sunday, March 30, 2003 11:27 PM +0200 Graham Leggett [EMAIL PROTECTED]
wrote:
I will take the code out of buildconf until it can be fixed. I was not aware
of these portability issues, having used the same techniques used in the
spec file (which in hindsight is obviously redhat specific).
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
From: Robert Howard [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date:
+1 for 2.0.45
Brian
On Sun, 2003-03-30 at 20:44, [EMAIL PROTECTED] wrote:
wrowe 2003/03/30 20:44:11
Modified:modules/generators mod_cgid.c
Log:
Solve segfaults from unusual error exceptions in cgid. The daemon
has no 'real' request_rec, so we can't use
At 07:34 AM 3/30/2003, Jeff Trawick wrote:
oh darn, I took a wild branch... this doesn't have anything to do with
cgid_child_errfn at all... it is this code, isn't it??? (look at Sander's minimal
traceback (which would be much better with a -g build and line numbers!!!))
rc =
One, win32 won't compile (nor any platform missing chown). In this
case we didn't need it and have a good macro to look at.
This raised another bug in the next line. We assumed because we
default to SYSV mutexes we should do that magic. I believe this is
wrong, and we should be looking for
--On Monday, March 31, 2003 12:53 AM -0600 William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
One, win32 won't compile (nor any platform missing chown). In this
case we didn't need it and have a good macro to look at.
Yup. Bad. It'd never get executed on them, but how is the compiler to know?
+1
Brian
On Sun, 2003-03-30 at 22:53, William A. Rowe, Jr. wrote:
One, win32 won't compile (nor any platform missing chown). In this
case we didn't need it and have a good macro to look at.
This raised another bug in the next line. We assumed because we
default to SYSV mutexes we should
26 matches
Mail list logo
