You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <CO...@PROCESS.COM> on 1997/11/12 20:05:00 UTC
[BUG] AllowOverride not allowed in VirtualHost..???
I just rebuilt my server from the latest CVS tree and restarted it,
and got this:
Syntax error on line 788 of /usr/local/web/server/conf/httpd.conf:
AllowOverride cannot occur within <VirtualHost> section
The statement in question is inside a <Directory> container within
a <VirtualHost> container, and it certainly *should* be allowed..
#ken P-(}
Date: 12 Nov 1997 21:56:39 -0000
From: new-httpd-owner@apache.org
To: new-httpd-owner@apache.org
Subject: BOUNCE new-httpd@apache.org: Non-member submission from [COAR@PROCESS.COM (Rodent of Unusual Size)]
Received: (qmail 5483 invoked from network); 12 Nov 1997 21:56:38 -0000
Received: from alcor.process.com (192.42.95.16)
by taz.hyperreal.org with SMTP; 12 Nov 1997 21:56:38 -0000
Date: Wed, 12 Nov 1997 16:55 -0400
From: COAR@PROCESS.COM (Rodent of Unusual Size)
Message-Id: <00...@PROCESS.COM>
To: new-httpd@apache.org
Subject: RE: [STATUS] 1.3b3-dev Tue Nov 11 18:00:34 EST 1997
X-VMS-To: SMTP%"new-httpd@apache.org"
X-VMS-Cc: COAR
>
>Available:
>
> * Ken's [PATCH] ReadmeName and !FancyIndexing (PR#1373)
> <00...@PROCESS.COM>
> Status: Ken +1,
Committed.
>Needs patch:
* Config parsing incorrectly gritching about AllowOverrides inside
a <Directory> inside a <VirtualHost> (doesn't like it being inside a
<VirtualHost>).
<msgid not yet available>
Fallout from Martin's directive-location-validity patch; I think
the NOT_IN_VIRTUALHOST flag needs to be removed from its check.
>Open issues:
* Ken suggests that new check_cmd_context() and related defines
should be non-static and in util_* so modules can use 'em. (He
didn't notice this flaw during the review.)
#ken P-)}
Date: 12 Nov 1997 20:29:48 -0000
From: new-httpd-owner@apache.org
To: new-httpd-owner@apache.org
Subject: BOUNCE new-httpd@apache.org: Non-member submission from [Dean Gaudet <dg...@arctic.org>]
Received: (qmail 6268 invoked from network); 12 Nov 1997 20:29:47 -0000
Received: from twinlark.arctic.org (204.62.130.91)
by taz.hyperreal.org with SMTP; 12 Nov 1997 20:29:47 -0000
Received: (qmail 1818 invoked by uid 500); 12 Nov 1997 20:29:46 -0000
Date: Wed, 12 Nov 1997 12:29:46 -0800 (PST)
From: Dean Gaudet <dg...@arctic.org>
To: Apache List <ne...@apache.org>
Subject: Re: Win32 16k problem nailed!
In-Reply-To: <34...@algroup.co.uk>
Message-ID: <Pi...@twinlark.arctic.org>
Organization: Transmeta Corp.
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On a similar topic ... I seem to recall someone here saying listen()
limits you to a backlog of 5 under win32 including NT... and that the only
way around this was to use completion ports, which requires a complete
revamp of how you do I/O. Which also happens to fix the below problem.
But definately isn't an easy thing to do for someone just wanting to port
a unix app.
Dean
On Wed, 12 Nov 1997, Ben Laurie wrote:
> OK, I've now traced the cause of the problem, and fixed it.
>
> Executive summary: Win32 select() is broken.
>
> Full story: Because there's no such thing as alarm() on Windoze, doing
> timeouts on read()s and write()s must be simulated. The strategy
> employed is as follows (this may not be the best way of doing, but its
> what we've got at the moment):
>
> 1. put socket in non-blocking mode.
> 2. attempt the write
> 3. if the write succeeds, we're done.
> 4. select on the socket, with timeout set to remaining time
> 5. write again
>
> What happens is that sometimes, on some machines, the select returns
> with write available, _but_ the write (at step 5) still says it will
> block. Now, I thought at first that this could be correct - all select
> is saying is that it can write a single byte to the socket, but we are
> (typically) attempting to write 8k. So, I wrapped the write in a loop
> that tried successively smaller amounts. I thought this should have
> fixed the problem, but didn't - it gets all the way down to 1 byte and
> _still_ fails. So, I added another loop - if we get down to 1 byte,
> sleep for 100 milliseconds, and try again. This works.
>
> Further thought, and manual reading, says that the "step down the size"
> strategy should not be needed - if there is insufficient space for the
> whole buffer, a partial write should occur. So, I'll eliminate that,
> leave in the retry loop, go for one more test, and commit. I'll leave a
> logging message warning that Windoze is broken.
>
> Cheers,
>
> Ben.
>
>
> --
> Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
> Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
> and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
> A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
>
Date: 12 Nov 1997 20:46:30 -0000
From: new-httpd-owner@apache.org
To: new-httpd-owner@apache.org
Subject: BOUNCE new-httpd@apache.org: Non-member submission from [Dean Gaudet <dg...@arctic.org>]
Received: (qmail 12924 invoked from network); 12 Nov 1997 20:46:28 -0000
Received: from twinlark.arctic.org (204.62.130.91)
by taz.hyperreal.org with SMTP; 12 Nov 1997 20:46:28 -0000
Received: (qmail 2578 invoked by uid 500); 12 Nov 1997 20:46:28 -0000
Date: Wed, 12 Nov 1997 12:46:28 -0800 (PST)
From: Dean Gaudet <dg...@arctic.org>
To: new-httpd@apache.org
Subject: Re: protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request (fwd)
In-Reply-To: <97...@paris.ics.uci.edu>
Message-ID: <Pi...@twinlark.arctic.org>
Organization: Transmeta Corp.
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Nov 1997, Roy T. Fielding wrote:
> >> See discard_request_body in http_protocol.c. ... unfortunately it looks to
> >> only be called by default_handler() and not die().
>
> Yep, I mentioned this when I made the original patch -- mod_cgi fails
> to do the right thing. However, I didn't think about using die() to
> do it for us. All it would require is the addition of
>
> dummy = discard_request_body(r);
>
> which is safe to call even if there is no body or it has already been read.
Jim can you put this in "Open issues"? We need to ensure all of our
content handlers do it.
> >I thought that Apache doesn't keep alive any error messages that came
> >from a request with an entity, for this reason. Maybe I'm remembering
> >incorrectly.
>
> That changed around 1.2b8 or so.
Right, mea culpa. That was when I was studying the performance for the
w3c pipelining paper ... and noticed that we dealt atrociously with a
pipeline full of GET If-Modified-Since requests. Or something like that.
Dean
Date: 12 Nov 1997 21:36:19 -0000
From: new-httpd-owner@apache.org
To: new-httpd-owner@apache.org
Subject: BOUNCE new-httpd@apache.org: Non-member submission from [Dean Gaudet <dg...@arctic.org>]
Received: (qmail 28436 invoked from network); 12 Nov 1997 21:36:18 -0000
Received: from twinlark.arctic.org (204.62.130.91)
by taz.hyperreal.org with SMTP; 12 Nov 1997 21:36:18 -0000
Received: (qmail 4860 invoked by uid 500); 12 Nov 1997 21:36:18 -0000
Date: Wed, 12 Nov 1997 13:36:18 -0800 (PST)
From: Dean Gaudet <dg...@arctic.org>
To: new-httpd@apache.org
Subject: Re: SunOS build
In-Reply-To: <97...@gensym1.gensym.com>
Message-ID: <Pi...@twinlark.arctic.org>
Organization: Transmeta Corp.
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
This looks right to me ... +1, but I have no way of testing it. I figured
SUNOS_LIB_PROTOTYPES was always defined... I guess the only time it
shouldn't be defined is if you have a gnu libc system. Perhaps it should
be a true/false define so glibc folks can disable it.
Dean
On Wed, 12 Nov 1997, Ben Hyde wrote:
> With Martin's additions to the SUNOS_LIB_PROTOTYPES section
> in conf.h. I can now tame the SunOS build (at least for
> my version of SunOS). Diff shown below
>
> Meanwhile the problem with long filenames reported in
> general/1404 apparently has two manifestations. On SunOS
> is causes these warnings.
>
> ar: filename mod_log_config.o truncated to mod_log_config.
> ar: filename mod_negotiation.o truncated to mod_negotiation
>
> But it doesn't prevent the link from succeeding.
>
> - ben
>
> ---
>
> Always enable SUNOS_LIB_PROTOTYPES since it's now needed.
> Add a few const declarations there in to eliminate warnings
> that it's arrival would otherwise trigger.
>
>
> > cvs diff -c conf.h
> Index: conf.h
> ===================================================================
> RCS file: /cvs/apachen/src/main/conf.h,v
> retrieving revision 1.157
> diff -c -r1.157 conf.h
> *** conf.h 1997/11/11 23:04:15 1.157
> --- conf.h 1997/11/12 21:20:21
> ***************
> *** 117,122 ****
> --- 117,123 ----
> #define USE_FLOCK_SERIALIZED_ACCEPT
> #define NEED_DIFFTIME
> #define HAVE_SYSLOG
> + #define SUNOS_LIB_PROTOTYPES
>
> #elif defined(SOLARIS2)
> #undef HAVE_GMTOFF
> ***************
> *** 923,930 ****
>
> int getopt(int, char **, char *);
>
> ! int strcasecmp(char *, char *);
> ! int strncasecmp(char *, char *, int);
> int toupper(int);
> int tolower(int);
>
> --- 924,931 ----
>
> int getopt(int, char **, char *);
>
> ! int strcasecmp(const char *, const char *);
> ! int strncasecmp(const char *, const char *, int);
> int toupper(int);
> int tolower(int);
>
> ***************
> *** 945,951 ****
> void perror(char *);
>
> time_t time(time_t *);
> ! int strftime(char *, int, char *, struct tm *);
>
> int initgroups(char *, int);
> int wait3(int *, int, void *); /* Close enough for us... */
> --- 946,952 ----
> void perror(char *);
>
> time_t time(time_t *);
> ! int strftime(char *, int, const char *, struct tm *);
>
> int initgroups(char *, int);
> int wait3(int *, int, void *); /* Close enough for us... */
> ***************
> *** 969,975 ****
> void syslog(int, char *,...);
> char *mktemp(char *);
>
> ! long vfprintf(FILE *, char *, va_list);
>
> #endif /* SUNOS_LIB_PROTOTYPES */
>
> --- 970,976 ----
> void syslog(int, char *,...);
> char *mktemp(char *);
>
> ! long vfprintf(FILE *, const char *, va_list);
>
> #endif /* SUNOS_LIB_PROTOTYPES */
>
> >
>
Date: 12 Nov 1997 21:07:03 -0000
From: new-httpd-owner@apache.org
To: new-httpd-owner@apache.org
Subject: BOUNCE new-httpd@apache.org: Non-member submission from [Marc Slemko <ma...@worldgate.com>]
Received: (qmail 20100 invoked from network); 12 Nov 1997 21:07:01 -0000
Received: from valis.worldgate.com (marcs@198.161.84.2)
by taz.hyperreal.org with SMTP; 12 Nov 1997 21:07:01 -0000
Received: from localhost (marcs@localhost)
by valis.worldgate.com (8.8.7/8.8.7) with SMTP id OAA24881
for <ne...@apache.org>; Wed, 12 Nov 1997 14:06:53 -0700 (MST)
Date: Wed, 12 Nov 1997 14:06:53 -0700 (MST)
From: Marc Slemko <ma...@worldgate.com>
To: new-httpd@apache.org
Subject: Re: general/1404: doesnt build due to BSD file name length restri ctions (fwd)
In-Reply-To: <19...@deejai.mch.sni.de>
Message-ID: <Pi...@valis.worldgate.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Nov 1997, Martin Kraemer wrote:
> On Wed, Nov 12, 1997 at 12:03:29PM -0500, Ben Hyde wrote:
> > I believe this is only a warning, the server still links fine.
> > Sunos gets these too, but not today (1.3b3-dev) since it get's stuck at
> > the fgetc isn't declared in stdio problem. - ben
>
> There's a set of prototypes in conf.h which are meant to be used on SUNOS
> (and SUNOS only): they declare the missing prototypes iff the #define
> SUNOS_LIB_PROTOTYPES is set. I added prototypes for fgets() and fgetc()
> to this set of prototypes yesterday. My question now is: did anything
> change, or is possibly the #define SUNOS_LIB_PROTOTYPES not set on your
> platform? Can you please re-check and report either to the list
> (preferred) or to my personnally? I would like to eliminate this compile
> failure before the official distribution of 1.3b3.
>
SUNOS_LIB_PROTOTYPES is never set. I am of the opinion that prototyping
two million functions like we would have to do for SunOS 4.x by default is
bad karma.
It works fine if you move the declaration outside to an ifdefed SUNOS
section after stdio.h is included. I would suggest that these two should
be seperated from the others in SUNOS_LIB_PROTOTYPES.
Date: 12 Nov 1997 21:10:22 -0000
From: new-httpd-owner@apache.org
To: new-httpd-owner@apache.org
Subject: BOUNCE new-httpd@apache.org: Non-member submission from [Marc Slemko <ma...@worldgate.com>]
Received: (qmail 20552 invoked from network); 12 Nov 1997 21:10:21 -0000
Received: from valis.worldgate.com (marcs@198.161.84.2)
by taz.hyperreal.org with SMTP; 12 Nov 1997 21:10:21 -0000
Received: from localhost (marcs@localhost)
by valis.worldgate.com (8.8.7/8.8.7) with SMTP id OAA25004
for <ne...@apache.org>; Wed, 12 Nov 1997 14:10:17 -0700 (MST)
Date: Wed, 12 Nov 1997 14:10:17 -0700 (MST)
From: Marc Slemko <ma...@worldgate.com>
To: "'new-httpd@apache.org'" <ne...@apache.org>
Subject: RE: general/1404: doesnt build due to BSD file name length restri ctions (fwd)
In-Reply-To: <40...@gensym-nt2.gensym.com>
Message-ID: <Pi...@valis.worldgate.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Nov 1997, Ben Hyde wrote:
> I believe this is only a warning, the server still links fine.
Not according to the reporter.
> Sunos gets these too, but not today (1.3b3-dev) since it get's stuck at
> the
> fgetc isn't declared in stdio problem. - ben
I don't get them on:
SunOS gsb009 4.1.4 1 sun4c unknown
Anyone have a BSD/OS box?
>
> > -----Original Message-----
> > From: Marc Slemko [SMTP:marcs@znep.com]
> > Sent: Wednesday, November 12, 1997 11:36 AM
> > To: TLOSAP
> > Subject: general/1404: doesnt build due to BSD file name length
> > restrictions (fwd)
> >
> > I don't beleive it. I just don't. They can't be that dumb.
> > mod_negotiation.o has been there since... since... 1.1.1. Oh. It
> > wasn't
> > in a library before. Damn.
> >
> >
> >
> > ---------- Forwarded message ----------
> > Date: 12 Nov 1997 15:36:57 -0000
> > From: Aaron Wohl <n3...@cmu.edu>
> > To: apbugs@hyperreal.org
> > Subject: general/1404: doesnt build due to BSD file name length
> > restrictions
> >
> >
> > >Number: 1404
> > >Category: general
> > >Synopsis: doesnt build due to BSD file name length restrictions
> > >Confidential: no
> > >Severity: critical
> > >Priority: medium
> > >Responsible: apache
> > >State: open
> > >Class: sw-bug
> > >Submitter-Id: apache
> > >Arrival-Date: Wed Nov 12 07:40:01 PST 1997
> > >Last-Modified:
> > >Originator: n3liw+@cmu.edu
> > >Organization:
> > apache
> > >Release: 1.3b2
> > >Environment:
> > BSD/OS karnov.nac.net 3.0 BSDI BSD/OS 3.0 Kernel #1: Fri Jul 18
> > 10:10:27 EDT 1997 root@:/usr/src/sys/compile/CHESS i386
> > >Description:
> > Gets the following errors:
> >
> > ar: warning: mod_log_config.o truncated to mod_log_config.
> > ar: warning: mod_negotiation.o truncated to mod_negotiation
> >
> > This is due to the file names being too long.
> > >How-To-Repeat:
> > Let me know if you need BSDI 3.1 system to test on
> > >Fix:
> > Yes, rename the two source files and two lines in Configuration and it
> > works fine
> > >Audit-Trail:
> > >Unformatted:
>
Date: 12 Nov 1997 21:56:46 -0000
From: new-httpd-owner@apache.org
To: new-httpd-owner@apache.org
Subject: BOUNCE new-httpd@apache.org: Non-member submission from [Marc Slemko <ma...@worldgate.com>]
Received: (qmail 5505 invoked from network); 12 Nov 1997 21:56:45 -0000
Received: from valis.worldgate.com (marcs@198.161.84.2)
by taz.hyperreal.org with SMTP; 12 Nov 1997 21:56:45 -0000
Received: from localhost (marcs@localhost)
by valis.worldgate.com (8.8.7/8.8.7) with SMTP id OAA27990
for <ne...@apache.org>; Wed, 12 Nov 1997 14:56:44 -0700 (MST)
Date: Wed, 12 Nov 1997 14:56:44 -0700 (MST)
From: Marc Slemko <ma...@worldgate.com>
To: new-httpd@apache.org
Subject: Re: SunOS build
In-Reply-To: <97...@gensym1.gensym.com>
Message-ID: <Pi...@valis.worldgate.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 12 Nov 1997, Ben Hyde wrote:
> With Martin's additions to the SUNOS_LIB_PROTOTYPES section
> in conf.h. I can now tame the SunOS build (at least for
> my version of SunOS). Diff shown below
I'm not sure I like enabling all those declarations. I am worried it is
likely to cause more problems than it will fix.
>
> Meanwhile the problem with long filenames reported in
> general/1404 apparently has two manifestations. On SunOS
> is causes these warnings.
>
> ar: filename mod_log_config.o truncated to mod_log_config.
> ar: filename mod_negotiation.o truncated to mod_negotiation
What ar are you using?
>
> But it doesn't prevent the link from succeeding.
>
> - ben
>
> ---
>
> Always enable SUNOS_LIB_PROTOTYPES since it's now needed.
> Add a few const declarations there in to eliminate warnings
> that it's arrival would otherwise trigger.
>
>
> > cvs diff -c conf.h
> Index: conf.h
> ===================================================================
> RCS file: /cvs/apachen/src/main/conf.h,v
> retrieving revision 1.157
> diff -c -r1.157 conf.h
> *** conf.h 1997/11/11 23:04:15 1.157
> --- conf.h 1997/11/12 21:20:21
> ***************
> *** 117,122 ****
> --- 117,123 ----
> #define USE_FLOCK_SERIALIZED_ACCEPT
> #define NEED_DIFFTIME
> #define HAVE_SYSLOG
> + #define SUNOS_LIB_PROTOTYPES
>
> #elif defined(SOLARIS2)
> #undef HAVE_GMTOFF
> ***************
> *** 923,930 ****
>
> int getopt(int, char **, char *);
>
> ! int strcasecmp(char *, char *);
> ! int strncasecmp(char *, char *, int);
> int toupper(int);
> int tolower(int);
>
> --- 924,931 ----
>
> int getopt(int, char **, char *);
>
> ! int strcasecmp(const char *, const char *);
> ! int strncasecmp(const char *, const char *, int);
> int toupper(int);
> int tolower(int);
>
> ***************
> *** 945,951 ****
> void perror(char *);
>
> time_t time(time_t *);
> ! int strftime(char *, int, char *, struct tm *);
>
> int initgroups(char *, int);
> int wait3(int *, int, void *); /* Close enough for us... */
> --- 946,952 ----
> void perror(char *);
>
> time_t time(time_t *);
> ! int strftime(char *, int, const char *, struct tm *);
>
> int initgroups(char *, int);
> int wait3(int *, int, void *); /* Close enough for us... */
> ***************
> *** 969,975 ****
> void syslog(int, char *,...);
> char *mktemp(char *);
>
> ! long vfprintf(FILE *, char *, va_list);
>
> #endif /* SUNOS_LIB_PROTOTYPES */
>
> --- 970,976 ----
> void syslog(int, char *,...);
> char *mktemp(char *);
>
> ! long vfprintf(FILE *, const char *, va_list);
>
> #endif /* SUNOS_LIB_PROTOTYPES */
>
> >
>
Date: 12 Nov 1997 22:18:06 -0000
From: new-httpd-owner@apache.org
To: new-httpd-owner@apache.org
Subject: BOUNCE new-httpd@apache.org: Non-member submission from [Marc Slemko <ma...@worldgate.com>]
Received: (qmail 11246 invoked from network); 12 Nov 1997 22:18:04 -0000
Received: from valis.worldgate.com (marcs@198.161.84.2)
by taz.hyperreal.org with SMTP; 12 Nov 1997 22:18:04 -0000
Received: from localhost (marcs@localhost)
by valis.worldgate.com (8.8.7/8.8.7) with SMTP id PAA29498
for <ne...@apache.org>; Wed, 12 Nov 1997 15:18:00 -0700 (MST)
Date: Wed, 12 Nov 1997 15:18:00 -0700 (MST)
From: Marc Slemko <ma...@worldgate.com>
To: Apache - BYOC <ne...@apache.org>
Subject: before 1.3b3...
Message-ID: <Pi...@valis.worldgate.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
strtoul should be fixed
Hmm. BSD is easy enough to steal and reasonably clean, but I don't like
the copyright issues.
fnmatch.c has the same things I guess. I'm not sure we comply with the
licensing terms though. And any third party product (eg. Stronghold)
would certainly need to include:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
even if we could sneak by without it.
Date: 12 Nov 1997 22:30:04 -0000
From: new-httpd-owner@apache.org
To: new-httpd-owner@apache.org
Subject: BOUNCE new-httpd@apache.org: Non-member submission from [Marc Slemko <ma...@worldgate.com>]
Received: (qmail 13151 invoked from network); 12 Nov 1997 22:30:01 -0000
Received: from valis.worldgate.com (marcs@198.161.84.2)
by taz.hyperreal.org with SMTP; 12 Nov 1997 22:30:01 -0000
Received: from localhost (marcs@localhost)
by valis.worldgate.com (8.8.7/8.8.7) with SMTP id PAA00303
for <ne...@apache.org>; Wed, 12 Nov 1997 15:29:59 -0700 (MST)
Date: Wed, 12 Nov 1997 15:29:58 -0700 (MST)
From: Marc Slemko <ma...@worldgate.com>
Reply-To: Marc Slemko <ma...@worldgate.com>
To: Apache - BYOC <ne...@apache.org>
Subject: [PATCH] fix buildmark
Message-ID: <Pi...@valis.worldgate.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Index: Makefile.tmpl
===================================================================
RCS file: /export/home/cvs/apachen/src/Makefile.tmpl,v
retrieving revision 1.70
diff -u -r1.70 Makefile.tmpl
--- Makefile.tmpl 1997/11/05 12:48:13 1.70
+++ Makefile.tmpl 1997/11/12 22:29:02
@@ -27,8 +27,6 @@
@false
$(TARGET): subdirs modules.o
- rm -f buildmark.c
- echo 'const char SERVER_BUILT[] = "'`date`'";' > buildmark.c
$(CC) -c $(CFLAGS) buildmark.c
$(CC) $(CFLAGS) $(LDFLAGS) -o $(TARGET) buildmark.o $(OBJS)
$(REGLIB) $(LIBS)
and create a buildmark.c of:
#if defined(__DATE__) && defined(__TIME__)
const char SERVER_BUILT[] = __DATE__ " " __TIME__;
#else
const char SERVER_BUILT[] = "unknown";
#endif
The NT makefiles still would need to be modified to include buildmark.c,
but that should be easy...
Date: 12 Nov 1997 18:11:18 -0000
From: new-httpd-owner@apache.org
To: new-httpd-owner@apache.org
Subject: BOUNCE new-httpd@apache.org: Non-member submission from [rse@engelschall.com (Ralf S. Engelschall)]
Received: (qmail 25023 invoked from network); 12 Nov 1997 18:11:15 -0000
Received: from colin.muc.de (root@193.174.4.1)
by taz.hyperreal.org with SMTP; 12 Nov 1997 18:11:15 -0000
Received: from en by colin.muc.de with UUCP id <86028-2>; Wed, 12 Nov 1997 19:10:52 +0100
Received: by en1.engelschall.com (Sendmail 8.8.8) for new-httpd@apache.org
id SAA19458; Wed, 12 Nov 1997 18:25:00 +0100 (MET)
Message-Id: <19...@en1.engelschall.com>
Subject: Re: cvs
To: new-httpd@apache.org
Date: Wed, 12 Nov 1997 18:24:59 +0100
From: rse@engelschall.com (Ralf S. Engelschall)
Organization: Engelschall, Germany.
Reply-To: rse@engelschall.com
X-Home: http://www.engelschall.com/
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
In article <Pi...@twinlark.arctic.org> you wrote:
> FWIW, CVSup is publicly available from taz now... we just need to document
> how you use it. Ralf, wanna open up that doc of yours?
Yes, Brian already said some time ago that CVSup is ready for public
consumption, so I now made the document public. The URL is:
http://www.engelschall.com/pw/private/apacherepos/
I'll add some infos about CVSup'ing only the HEAD in the next days, too.
Greetings,
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com