You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Manoj Kasichainula <ma...@io.com> on 2000/03/26 13:49:44 UTC
Two 2.0 problems
Before I sleep, here's a couple of things I noticed:
1. mod_include isn't building.
mod_include.c: In function `sub_send_parsed_file':
mod_include.c:2376: dereferencing pointer to incomplete type
mod_include.c:2377: parse error before `request_rec'
mod_include.c:2379: `r' undeclared (first use in this function)
mod_include.c:2379: (Each undeclared identifier is reported only once
mod_include.c:2379: for each function it appears in.)
mod_include.c:2384: too few arguments to function `ap_thread_exit'
mod_include.c:2389: too few arguments to function `ap_thread_exit'
mod_include.c:2398: too few arguments to function `ap_thread_exit'
mod_include.c:2407: too few arguments to function `ap_thread_exit'
mod_include.c:2421: too few arguments to function `ap_thread_exit'
mod_include.c:2429: too few arguments to function `ap_thread_exit'
mod_include.c:2470: too few arguments to function `ap_thread_exit'
mod_include.c: In function `send_parsed_file':
mod_include.c:2476: storage size of `dumb_rec' isn't known
mod_include.c:2488: `bpipein' undeclared (first use in this function)
Yikes, we're trying to exit threads in mod_include? I need to pay more
attention to the commit logs.
2. apr.h is completely regenerated everytime configure is run. On the
good side, David's --prefix problem is solved. :) But, I'd rather have
only the things that need rebuilding be built. I think this can be
done by moving apr.h from AC_OUTPUT to AC_CONFIG_HEADERS, but I'm
sleeping now so I can't test this.
BTW, I have a replacement for the apaci script which uses a header
file to pass in the preprocessor macros. I need to rejigger a couple
of things first to simplify it first, but first I'm going to sleep.
Re: Two 2.0 problems
Posted by David Reid <dr...@jetnet.co.uk>.
Thanks Manoj. I'll check it later. Sleep well.
d.
----- Original Message -----
From: "Manoj Kasichainula" <ma...@io.com>
To: "Apache Developers" <ne...@apache.org>
Sent: Sunday, March 26, 2000 12:49 PM
Subject: Two 2.0 problems
> Before I sleep, here's a couple of things I noticed:
>
> 1. mod_include isn't building.
>
> mod_include.c: In function `sub_send_parsed_file':
> mod_include.c:2376: dereferencing pointer to incomplete type
> mod_include.c:2377: parse error before `request_rec'
> mod_include.c:2379: `r' undeclared (first use in this function)
> mod_include.c:2379: (Each undeclared identifier is reported only once
> mod_include.c:2379: for each function it appears in.)
> mod_include.c:2384: too few arguments to function `ap_thread_exit'
> mod_include.c:2389: too few arguments to function `ap_thread_exit'
> mod_include.c:2398: too few arguments to function `ap_thread_exit'
> mod_include.c:2407: too few arguments to function `ap_thread_exit'
> mod_include.c:2421: too few arguments to function `ap_thread_exit'
> mod_include.c:2429: too few arguments to function `ap_thread_exit'
> mod_include.c:2470: too few arguments to function `ap_thread_exit'
> mod_include.c: In function `send_parsed_file':
> mod_include.c:2476: storage size of `dumb_rec' isn't known
> mod_include.c:2488: `bpipein' undeclared (first use in this function)
>
> Yikes, we're trying to exit threads in mod_include? I need to pay more
> attention to the commit logs.
>
> 2. apr.h is completely regenerated everytime configure is run. On the
> good side, David's --prefix problem is solved. :) But, I'd rather have
> only the things that need rebuilding be built. I think this can be
> done by moving apr.h from AC_OUTPUT to AC_CONFIG_HEADERS, but I'm
> sleeping now so I can't test this.
>
> BTW, I have a replacement for the apaci script which uses a header
> file to pass in the preprocessor macros. I need to rejigger a couple
> of things first to simplify it first, but first I'm going to sleep.
>
>
Re: Two 2.0 problems
Posted by Jeff Trawick <tr...@bellsouth.net>.
(you certainly don't need to be told this, but perhaps if it saves
somebody 100 or so seconds)
work-arounds to get it to build...
win32: see patch below
everything else: --disable-include on configure
yea, this is losing, but I've got my own 10 lines of changes to get
rid of while Ryan and Greg chat about this stuff
===================================================================
RCS file: /cvs/apache/apache-2.0/src/modules/standard/mod_include.c,v
retrieving revision 1.24
diff -u -r1.24 mod_include.c
--- mod_include.c 2000/03/25 15:00:10 1.24
+++ mod_include.c 2000/03/26 14:51:50
@@ -2369,6 +2369,12 @@
request_rec *r;
} ssi_rec;
+int send_parsed_file(request_rec *r)
+{
+ return 0;
+}
+
+#if 0
void * API_THREAD_FUNC sub_send_parsed_file(void *rec)
{
ap_file_t *f = NULL;
@@ -2501,6 +2507,7 @@
return RERUN_HANDLERS;
}
+#endif
static int send_shtml_file(request_rec *r)
{
--
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: Two 2.0 problems
Posted by Manoj Kasichainula <ma...@io.com>.
On Sun, Mar 26, 2000 at 11:06:13AM -0500, Ryan Bloom wrote:
> > 2. apr.h is completely regenerated everytime configure is run. On the
> > good side, David's --prefix problem is solved. :) But, I'd rather have
> > only the things that need rebuilding be built. I think this can be
> > done by moving apr.h from AC_OUTPUT to AC_CONFIG_HEADERS, but I'm
> > sleeping now so I can't test this.
>
> apr.h shouldn't have anything to do with David's --prefix problem. I
> don't see the connection.
Because it's being regenerated everytime, and every Apache .c file
depends on it, so every .c file is being rebuilt everytime configure
is rerun. It was just a side note; the fundamental problem is the
regeneration of apr.h even when it's not necessary.
Re: Two 2.0 problems
Posted by rb...@apache.org.
> 1. mod_include isn't building.
mod_include was modified in a commit of mine, but I thought I had moved
mod_include out of the way. I'll fix this today or tomorrow.
>
> Yikes, we're trying to exit threads in mod_include? I need to pay more
> attention to the commit logs.
>
It's required for the layered I/O stuff. Trust me, when this is done,
it'll make sense.
> 2. apr.h is completely regenerated everytime configure is run. On the
> good side, David's --prefix problem is solved. :) But, I'd rather have
> only the things that need rebuilding be built. I think this can be
> done by moving apr.h from AC_OUTPUT to AC_CONFIG_HEADERS, but I'm
> sleeping now so I can't test this.
apr.h shouldn't have anything to do with David's --prefix problem. I
don't see the connection.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------