Re: S_L_U_A for worker MPM?

[Ryan Bloom]

The easiest way to remove the S_L_U_A from the worker MPM is to remove all
signals from the MPM.  Basically, we have a single thread that currently
sits in sigwait, which is just waiting for a signal.  We then have every
other thread sitting in accept waiting for something to wake them up,
either a real connection or a fake one for the POD.  It makes a lot of
sense to make the parent process always use the POD for all
communication.  If this happens, then the thread sitting in sigwait could
easily just sit in poll waiting for data from the parent.  If it gets a !,
then the process should just die, if it gets a #, then it should perform a
graceful (The chars don't matter, just the idea).  Since the thread in
poll() is always the main thread, it is just fine to just call exit to
terminate the process immediately.  The biggest problem will be how to
wake up the thread that is currently sitting in accept.

Ryan

On Mon, 21 Jan 2002, Greg Ames wrote:

> Brian Pane wrote:
> 
> > I'm willing to spend some time this week on this issue, but first, can
> > somebody clarify how prefork is handling the pipe-of-death?
> > 
> > It looks like prefork children only check the pod upon completion of
> > a request.  Is that all there is to it, or am I missing something?
> 
> There has to be a way to unblock accept()s when a graceful restart happens in
> order to get rid of the apr_poll.  I think prefork depends on the logic in
> mpm_common.c::ap_mpm_pod_[signal|killpg] that sends dummy connects to do this in
> situations where there's low/no traffic from the network. (disclaimer: haven't
> studied the code recently)
> 
> btw, some of the workers_may_exit checks may not be necessary any more, so we
> might be able to eliminate some conditional branches in the mainline path.  The
> threaded MPM had the possibility of workers_may_exit getting set asynchronously
> on thread x, and apparently we wanted thread y to know ASAP. (same disclaimer)
> 
> Greg
> 

-- 

___
Ryan Bloom  [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---

Re: Tagging 1.3.23

[Victor J. Orlikowski]

Hrm.Gave things a second look.

Thomas, I think your fix is fine. I will commit it shortly.

I think, however, that a more reliable option with the various Linux
distributions may be to use the DBM_LIB variable a little more in
src/Configure. If we can determine the linux distribution being used,
we could simply set DBM_LIB as needed, and simplify find-dbm-lib down
to the default case.

On RedHat, I know that version info is kept in /etc/redhat-release.
Is there something similar on other distributions (I ask about Debian
in particular, as I am rather ignorant of its setup)?

Victor
-- 
Victor J. Orlikowski   | The Wall is Down, But the Threat Remains!
==
[EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL PROTECTED]

[PATCH] ap_rgetline rewrite

[Justin Erenkrantz]

As discussed before, here is an implementation rewrite of 
ap_rgetline.  I'd appreciate it if people could review before I 
consider committing it.  =)  It passes all of the httpd-tests (this
is why I've been adding AP_MODE_SPECULATIVE).

The rationale behind this rewrite is to remove the req_cfg->bb
usage so that no data is stored outside of the filter chain.
This is just pure ugliness and needs to be eradicated.

A few notes:
- ap_rgetline has a brand new prototype.  Since there are only
  a few callers of ap_rgetline (and all of them are restricted to
  protocol.c), I think it is worth changing it now.  ap_getline
  has been modified to present the old API.  I imagine that we 
  could try to tackle changing ap_getline to be more sane in 
  another pass.  I'd prefer to do this in increments.
  (Granted, I could rewrite ap_rgetline without changing the API,
   but yuck...)
- We return APR_ENOSPC when we are out of buffer space.  I couldn't
  think up a better error code.  If you have a better idea, I'm all
  ears.  I really dislike the len==n means we ran out of space 
  semantic.  (APR_ENOMEM?)
- ap_rgetline is now recursive in two cases:
- We didn't get a LF from ap_get_brigade
- We are doing MIME folding
  I think the logical flow is now much better, so I think the 
  potential speed costs of recursion is balanced by the fact 
  that this code just might be maintainable.  However, this has 
  two drawbacks:
- We have to do an extra malloc/copy on return when we do the
  allocation (i.e. NULL is passed in).  We don't know what
  ending size will be, so we have to pass NULL to our "child"
  so that it can control the memory allocation.  So, we'll have
  two disjoint buffers that we need to merge together.
- I think recursion makes a complete mess out of the xlate code.  
  I'm not entirely sure that this code works on EBCDIC machines.
  I don't have access to one, but we could introduce an
  intermediate call that just does the xlate call on EBCDIC
  machines (ap_rgetline_real and ap_rgetline).  You'd call
  ap_rgetline which would do just the following:
ap_rgetline_real(s, foo, bar, baz...);
ap_xlate_from_ascii(s, what length we read);

  I wish EBCDIC was hidden by filters.  *sigh*

I have included the new ap_[r]getline in its entirety (since it's a
big diff) so that it is easy to review and a complete patch follows.

Please let me know what you think.  Thanks.  -- justin

--
/* Get a line of protocol input, including any continuation lines
 * caused by MIME folding (or broken clients) if fold != 0, and place it
 * in the buffer s, of size n bytes, without the ending newline.
 *
 * If s is NULL, ap_rgetline will allocate necessary memory from r->pool.
 *
 * Returns APR_SUCCESS if there are no problems and sets *read to be
 * the full length of s.
 *
 * APR_ENOSPC is returned if there is not enough buffer space.
 * Other errors may be returned on other errors.
 *
 * The LF is *not* returned in the buffer.  Therefore, a *read of 0
 * indicates that an empty line was read.
 *
 * Notes: Because the buffer uses 1 char for NUL, the most we can return is 
 *(n - 1) actual characters.  
 *
 *If no LF is detected on the last line due to a dropped connection 
 *or a full buffer, that's considered an error.
 */
AP_DECLARE(apr_status_t) ap_rgetline(char **s, apr_size_t n, 
 apr_size_t *read, request_rec *r, 
 int fold)
{
apr_status_t rv;
apr_bucket_brigade *b;
apr_bucket *e;
apr_size_t bytes_handled = 0, current_alloc = 0;
apr_off_t bytes_read;
char *pos, *last_char = *s;
int do_alloc = (*s == NULL), saw_eos = 0;

b = apr_brigade_create(r->pool);
rv = ap_get_brigade(r->input_filters, b, AP_MODE_GETLINE,
APR_BLOCK_READ, &bytes_read);

if (rv != APR_SUCCESS) {
return rv;
}

/* Something horribly wrong happened.  Someone didn't block! */
if (APR_BRIGADE_EMPTY(b)) {
return APR_EGENERAL; 
}

APR_BRIGADE_FOREACH(e, b) {
const char *str;
apr_size_t len;

/* If we see an EOS, don't bother doing anything more. */
if (APR_BUCKET_IS_EOS(e)) {
saw_eos = 1; 
break;
}

rv = apr_bucket_read(e, &str, &len, APR_BLOCK_READ);

if (rv != APR_SUCCESS) {
apr_brigade_destroy(b);
return rv;
}

/* Would this overrun our buffer?  If so, we'll die. */
if (n < bytes_handled + len) {
apr_brigade_destroy(b); 
return APR_ENOSPC;
}

/* Do we have to handle the allocation ourselves? */
if (do_alloc) {
/* We'll assume the common case where one bucket is enough. */
if (!*s) {
current_alloc = len;
*s = apr_palloc(r->pool, len);
}

Re: APR_BRIGADE_NORMALIZE

[Justin Erenkrantz]

On Sun, Jan 20, 2002 at 10:36:47PM -0500, Cliff Woolley wrote:
> 
> Can someone please remind me why APR_BRIGADE_NORMALIZE is absolutely
> necessary?  It's only being used in one place AFAICT (in core.c), and as
> far as I know, that just means there's a bug we're patching around rather
> than fixing.  I was grudgingly okay with it until today, when it occurred
> to me that removing all zero-length buckets would nuke any third-party
> metadata buckets that might be in the brigade, meaning that it's a really
> bad idea.

IIRC, there are two cases where a zero-length bucket can be inserted
into a brigade in core_input_filter (aka CORE_IN):

- We read the end-of-the-socket via apr_bucket_read().  Remember that
  buckets may get "silently" morphed to another type.  We want to
  ensure that we don't get stuck into an infinite loop.  We prevent
  this by checking for APR_BRIGADE_EMPTY and if that's the case, we 
  return APR_EOF.  Remember that core_input_filter doesn't insert
  an EOS bucket - that is the job of HTTP_IN in Apache - all CORE_IN 
  knows is when we have exhausted our socket bucket (as indicated 
  when there are no buckets left).  

  Actually, in our current code when we have exhausted the socket
  bucket, we'd call core_input_filter with an 0-length brigade, 
  check for EMPTY, then normalize it, and continue on.  So, we 
  have one extra iteration before CORE_IN returns APR_EOF.  Oh, 
  well.

  The way to resolve this is to either stop morphing the bucket
  to a 0-length immortal bucket (and somehow remove that bucket
  from its brigade) or rewrite CORE_IN to not use the socket 
  bucket abstractions.  I *really* like using the socket bucket 
  abstraction in CORE_IN - just call apr_bucket_read and you don't
  have to deal with the socket code directly.  I also don't know
  how that would interfere with any "socket-compatible" layers -
  like FirstBill's fast-SSL sockets (which I believe was the
  rationale for Ryan's MPM rewrite a few months ago).

  The other alternative would be to somehow resolve the situation
  where the bucket is exhausted and remove that bucket rather than
  placing a 0-length bucket in its place.

- We split a bucket at the length of the bucket.  We will end up
  with a bucket with the exact length as before and a 0-length 
  bucket.  I proposed fixing the split semantics so that if the 
  split occurred at the length, it would be a no-op.  Both
  you (Cliff) and Ryan had objections to that.  I don't recall
  what your precise rationale was, but I dropped it and left the
  NORMALIZE call in with that "This is bad" comment.

I believe in practice, the second issue happens more often than 
the first.  Also, since this is the "lowest" level filter - I'm
not sure that any metadata would be stripped here.  Calling
normalize another place may be troublesome however - and the
issues listed here are just as pertinent there.  -- justin

Re: PHP Apache2Filter crashes on Win32

[Justin Erenkrantz]

On Mon, Jan 21, 2002 at 01:23:42PM +0100, Sebastian Bergmann wrote:
>   Here's a backtrace:
> 
> ap_save_brigade(ap_filter_t * 0x10d57628, apr_bucket_brigade * *
> 0x10d56004, apr_bucket_brigade * * 0x10a6fe74, apr_pool_t * 0x10d55b30)
> line 418 + 49 bytes
> php_output_filter(ap_filter_t * 0x10d57628, apr_bucket_brigade *
> 0x10d57790) line 350 + 32 bytes
> ap_pass_brigade(ap_filter_t * 0x10d57628, apr_bucket_brigade * 0x10d57790)
> line 390 + 16 bytes
> default_handler(request_rec * 0x10d55b68) line 2974
> ap_run_handler(request_rec * 0x10d55b68) line 186 + 78 bytes
> ap_invoke_handler(request_rec * 0x10d55b68) line 359 + 9 bytes
> ap_process_request(request_rec * 0x10d55b68) line 291 + 9 bytes
> ap_process_http_connection(conn_rec * 0x10cdc140) line 280 + 9 bytes
> ap_run_process_connection(conn_rec * 0x10cdc140) line 84 + 78 bytes
> ap_process_connection(conn_rec * 0x10cdc140) line 232
> worker_main(int 248) line 934
> _threadstartex(void * 0x005f4688) line 212 + 13 bytes
> 
>   Latest CVS of both Apache2 and PHP 4.

FWIW, I see segfaults in PHP4 all of the time in Unix when it
calls ap_save_brigade.  I even filed a PHP bug report a month 
ago today.  =)  

http://bugs.php.net/bug.php?id=14637

I think it is related to inproper use of ap_save_brigade, but I'm
not familiar enough with PHP to determine more.  I bet it is a
boundary condition that it isn't handling.  It *could* be something
we're doing wrong in ap_save_brigade, but I didn't see that from my
cursory examination.  The context looks like it has been 
corrupted.  -- justin

Re: Tagging 1.3.23

[Greg Stein]

On Mon, Jan 21, 2002 at 07:58:57PM -0500, Jim Jagielski wrote:
> I'm also thinking of the # of patches OtherBill is folding in
> as well... By "bumping" the tag, do you mean having the tag
> say something like APACHE_1_3_23_R2 or something? Not APACHE_1_3_24 
> right? :) :)
> 
> Bill Stoddard wrote:
> > 
> > The tarball hasn't been rolled, so if the change is simple, why not make the 
>change and
> > bump the tag?  This method has worked pretty good for 2.0 if we impose a 
>reasonable time
> > limit between the tag and the roll (say 24 hours).

+1 on Bill's suggestion.

And no, it wouldn't be funny tags. We'd just point the tag at a different
revision for that one file. For all intents and purposes, the fix is now
part of the 1.3.23 tag.

btw, Bill: you can/should still manually tag that .cvsignore to be correct.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: APR_BRIGADE_NORMALIZE

[Greg Stein]

On Sun, Jan 20, 2002 at 10:36:47PM -0500, Cliff Woolley wrote:
> 
> Can someone please remind me why APR_BRIGADE_NORMALIZE is absolutely
> necessary?  It's only being used in one place AFAICT (in core.c), and as
> far as I know, that just means there's a bug we're patching around rather
> than fixing.  I was grudgingly okay with it until today, when it occurred
> to me that removing all zero-length buckets would nuke any third-party
> metadata buckets that might be in the brigade, meaning that it's a really
> bad idea.

There was a bug somewhere with zero length buckets. I don't remember, and I
bet it doesn't exist now.

I say torch the damned thing. You're quite right: removing zero length
buckets is Bad Juju.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: Tagging 1.3.23

[Rodent of Unusual Size]

Thomas Eibner wrote:
> 
> Like this? I had to put the gdbm test after db1 since debian only has
> the gdbm-ndbm.h (but it has the db1/ndbm.h)

Yep, that does it -- at least on the RH 7.1 system; haven't
tried it on others.  -Wall -Wmissing-prototypes generates a
bunch o' messages for ndbm.h, but the server builds.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"Millenium hand and shrimp!"

Re: Tagging 1.3.23

[Jim Jagielski]

I'm also thinking of the # of patches OtherBill is folding in
as well... By "bumping" the tag, do you mean having the tag
say something like APACHE_1_3_23_R2 or something? Not APACHE_1_3_24 
right? :) :)

Bill Stoddard wrote:
> 
> The tarball hasn't been rolled, so if the change is simple, why not make the change 
>and
> bump the tag?  This method has worked pretty good for 2.0 if we impose a reasonable 
>time
> limit between the tag and the roll (say 24 hours).
> 
> Bill (who really doesn't mind if we go to 1.3.24)
> 
> > I have a feeling that this implies a 1.3.24... The real fix is
> > to include the correct header, or determine if it's even
> > needed.
> >
> > Thomas Eibner wrote:
> > >
> > > On Mon, Jan 21, 2002 at 03:53:31PM -0500, Rodent of Unusual Size wrote:
> > > > "Victor J. Orlikowski" wrote:
> > > > >
> > > > > Argh
> > > > > Not this *again*.
> > > > > *Sigh*.
> > > > > Which linux distribution?
> > > >
> > > > RH 7.1.  This was building for 1.3.22, so I'm pretty sure
> > > > this is something new.
> > >
> > > I just tried it on my debian, with the ndbm.h symbolic link it works,
> > > without it breaks. So I'd say it's a linux problem. It's been happening
> > > to me for ages on my new debian boxen until I did the link from gdbm-ndbm.h
> > >
> > > --
> > >   Thomas Eibner  DnsZone 
> > >   mod_pointer 
> > >
> >
> >
> > --
> > ===
> >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"
> >
> 


-- 
===
   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"

Re: modules/aaa/mod_auth_digest.c

[William A. Rowe, Jr.]

Madhu,

  Without looking at the code - that looks dead on, for the parent process 
only (probably best done in the pre_mpm hook).  We need to -attach- for 
children, rather that init (best in the child_init hook.)


From: "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <[EMAIL PROTECTED]>
Sent: Monday, January 21, 2002 4:17 PM


> I'm trying to understand the use of shm/rmm and I was wondering if
> it makes sense to have something like this in mod_auth_digest.c.
> 
> Thanks
> -Madhu
> 
> Index: mod_auth_digest.c
> ===
> RCS file: /home/cvspublic/httpd-2.0/modules/aaa/mod_auth_digest.c,v
> retrieving revision 1.58
> diff -u -r1.58 mod_auth_digest.c
> --- mod_auth_digest.c   10 Jan 2002 02:58:10 -  1.58
> +++ mod_auth_digest.c   21 Jan 2002 22:14:29 -
> @@ -311,6 +311,13 @@
>  return;
>  }
>  
> +sts = apr_rmm_init(&client_rmm, NULL, client_shm, shmem_size, ctx)
> +if (sts != APR_SUCCESS) {
> +log_error_and_cleanup("failed to initialize rmm", sts, s);
> +return;
> +}
> +
> +
>  client_list = apr_rmm_malloc(client_rmm, sizeof(*client_list) +
>  
> sizeof(client_entry*)*num_buckets);
>  if (!client_list) {
> 

Re: Tagging 1.3.23

[Cliff Woolley]

On Mon, 21 Jan 2002, Bill Stoddard wrote:

> in about 15 minutes...

FWIW, it builds and runs fine on slackware-current (8.x).

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA

modules/aaa/mod_auth_digest.c

[MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)]

Hi,
I'm trying to understand the use of shm/rmm and I was wondering if
it makes sense to have something like this in mod_auth_digest.c.

Thanks
-Madhu

Index: mod_auth_digest.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/aaa/mod_auth_digest.c,v
retrieving revision 1.58
diff -u -r1.58 mod_auth_digest.c
--- mod_auth_digest.c   10 Jan 2002 02:58:10 -  1.58
+++ mod_auth_digest.c   21 Jan 2002 22:14:29 -
@@ -311,6 +311,13 @@
 return;
 }
 
+sts = apr_rmm_init(&client_rmm, NULL, client_shm, shmem_size, ctx)
+if (sts != APR_SUCCESS) {
+log_error_and_cleanup("failed to initialize rmm", sts, s);
+return;
+}
+
+
 client_list = apr_rmm_malloc(client_rmm, sizeof(*client_list) +
 
sizeof(client_entry*)*num_buckets);
 if (!client_list) {

Re: Tagging 1.3.23

[Victor J. Orlikowski]

I still think that there has to be a better way, rather than patching
find-dbm-lib right and left based on wherever a vendor decided to put
their ndbm.h.

If no-one beats me to it, I'll prolly muck with this tonight.

Victor
-- 
Victor J. Orlikowski   | The Wall is Down, But the Threat Remains!
==
[EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL PROTECTED]

Re: WIN32 build

[Christian Gross]

I will put all the various emails together regarding the WIN32 build issues 
that I am having.

 >>
 >> 1) AWK is necessary and my AWK from Cygwin crashes everytime it is
 >> used. My Cygwin installation is up to date with the latest edition.
 >Sorry, then patch cyg-awk, or use another (see win_compling.html). I never
 >expect Cyg tools to run except within the Cyg shell.

Ok can do that.

 >> 2) Everything within the VC++ application is stored within in their
 >> respective DEBUG directories. With so many pieces now debugging has become
 >> very difficult. You cannot simply move the DLL since then the debugger
 >> becomes confused.
 >No, if you make makefile.win, or launch the InstallBin target, they work.

To be very frank here, if the DSW and DSP are there nobody uses the 
makefile.win.  And to debug I will need to load up all of the DLL's which 
adds quite a bit of work especially since there are so many modules.

 >> 3) To set breakpoints the DLL's have to pre-loaded into the debug space,
 >> otherwise you get a constant error of breakpoint not being able to set.
 >You can't do this without distributing the .opt file that corresponds to the
 >.dsw file. You can't do this, since .opt is localized to your machine paths.

The problem still is that I have to setup everything to be able to 
debug.  I would much more prefer if it went back to the old way of 
compilation where everything is in one DLL.  This makes debugging and the 
likes much easier.

 >> My suggestion is to create a project for building versions of Apache that
 >> people can use to build production capable releases. But for the debug
 >> crowd there is a simple project that is like the previous Apache build,
 >> where you loaded one project, hit build, set a breakpoint and debugged 
your
 >> sources.
 >>
 >> I can do this if so desired.
 >This is why I do _exactly_ that with the 'InstallBin.dps' makefile.mak 
project.
 >You are then debugging binaries deposited into your 'installed server'. We
 >can look at exactly what can be toggled, but this should be trivial.
 >I wish the .opt debugging info were global, unfortunately, it is not.

Ok point taken, but could we then change the other project back to what it 
was before the millions of modules?


At 12:51 21/01/2002 -0800, [EMAIL PROTECTED] wrote:
>On Mon, 21 Jan 2002, Christian Gross wrote:
>
> > I think it is great that all of the modules are dynamically loaded in the
> > latest builds of Apache.  But there is a problem, in that the dependencies
> > of libhttp.dll have not been altered.  Hence when building Apache not
> > everything is built and then there are version conflicts, etc, etc.
>
>What dependencies are missing?  When the magic number is updated you must
>rebuild all modules -

The problem is that when I do a CVS update not everything gets 
compiled.  Then when I attempt to run magic versions are not up to 
date.  Hence I do a clean and rebuild.  Then everything works again.


> > I update the dependencies, everytime I call a CVS update those changes are
> > then wacked.  Is it possible to get the dependencies updated?  Thanks
>
>why not submit a patch if you have the problem fixed?

All I would really like is to go back to the dsp files of about 1 week ago.

 >libhttpd.dll runs without any modules. Therefore it's isn't dependent
 >on them.
Correct, but the problem is with conf file.  When you run Apache in the dsw 
file and use the configuration file as given in the docs directory the 
modules will not load because the initial directory is set to the directory 
of the apache executable, which is within the debug directory.

The reason I am whining a bit is because I just did an update of the Apache 
sources from the CVS tree and I had to exert quite a bit of effort to get 
things to work.  I find that unlike before I need to do quite a bit of 
configuration work before anything works.  This is unlike the projects from 
before.  So could we go back to the older projects?

Christian

Re: Tagging 1.3.23

[Thomas Eibner]

On Mon, Jan 21, 2002 at 05:04:01PM -0500, Rodent of Unusual Size wrote:
> Thomas Eibner wrote:
> > 
> > Moving around on the way that find-dbm-lib looks for the libs works for
> > me on my Debian box. Is this going to break something else?
> 
> Without testing this patch (my 7.1 system just hung again),
> wouldn't we have to fix the CFLAGS to include "-I/usr/include/gdbm",
> though?

Like this? I had to put the gdbm test after db1 since debian only has
the gdbm-ndbm.h (but it has the db1/ndbm.h)

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  



Index: src/helpers/find-dbm-lib
===
RCS file: /home/cvspublic/apache-1.3/src/helpers/find-dbm-lib,v
retrieving revision 1.12
diff -u -r1.12 find-dbm-lib
--- src/helpers/find-dbm-lib17 Jan 2002 13:20:51 -  1.12
+++ src/helpers/find-dbm-lib21 Jan 2002 22:07:31 -
@@ -13,9 +13,7 @@
*-linux*)
# many systems don't have -ldbm
DBM_LIB=""
-   if ./helpers/TestCompile lib dbm dbm_open; then
-   DBM_LIB="-ldbm"
-   elif ./helpers/TestCompile lib ndbm dbm_open; then
+   if ./helpers/TestCompile lib ndbm dbm_open; then
DBM_LIB="-lndbm"
if ./helpers/TestCompile lib db1 dbm_open; then
# Red Hat needs this; ndbm.h lives in db1
@@ -25,6 +23,11 @@
# For Red Hat 7, if not handled by the ndbm case above
DBM_LIB="-ldb1"
CFLAGS="$CFLAGS -I/usr/include/db1"
+elif ./helpers/TestCompile lib gdbm dbm_open; then
+DBM_LIB="-lgdbm"
+CFLAGS="$CFLAGS -I/usr/include/gdbm"
+   elif ./helpers/TestCompile lib dbm dbm_open; then
+   DBM_LIB="-ldbm"
fi
if [ "x$DBM_LIB" != "x" ]; then
LIBS="$LIBS $DBM_LIB"

Re: Tagging 1.3.23

[Thomas Eibner]

On Mon, Jan 21, 2002 at 05:04:01PM -0500, Rodent of Unusual Size wrote:
> Thomas Eibner wrote:
> > 
> > Moving around on the way that find-dbm-lib looks for the libs works for
> > me on my Debian box. Is this going to break something else?
> 
> Without testing this patch (my 7.1 system just hung again),
> wouldn't we have to fix the CFLAGS to include "-I/usr/include/gdbm",
> though?

Your machine didn't have the db1 files? Why don't we just add another
test with the gdbm headers then? Need a patch?

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Re: Tagging 1.3.23

[Rodent of Unusual Size]

Thomas Eibner wrote:
> 
> Moving around on the way that find-dbm-lib looks for the libs works for
> me on my Debian box. Is this going to break something else?

Without testing this patch (my 7.1 system just hung again),
wouldn't we have to fix the CFLAGS to include "-I/usr/include/gdbm",
though?
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"Millenium hand and shrimp!"

Re: Tagging 1.3.23

[Bill Stoddard]

The tarball hasn't been rolled, so if the change is simple, why not make the change and
bump the tag?  This method has worked pretty good for 2.0 if we impose a reasonable 
time
limit between the tag and the roll (say 24 hours).

Bill (who really doesn't mind if we go to 1.3.24)

> I have a feeling that this implies a 1.3.24... The real fix is
> to include the correct header, or determine if it's even
> needed.
>
> Thomas Eibner wrote:
> >
> > On Mon, Jan 21, 2002 at 03:53:31PM -0500, Rodent of Unusual Size wrote:
> > > "Victor J. Orlikowski" wrote:
> > > >
> > > > Argh
> > > > Not this *again*.
> > > > *Sigh*.
> > > > Which linux distribution?
> > >
> > > RH 7.1.  This was building for 1.3.22, so I'm pretty sure
> > > this is something new.
> >
> > I just tried it on my debian, with the ndbm.h symbolic link it works,
> > without it breaks. So I'd say it's a linux problem. It's been happening
> > to me for ages on my new debian boxen until I did the link from gdbm-ndbm.h
> >
> > --
> >   Thomas Eibner  DnsZone 
> >   mod_pointer 
> >
>
>
> --
> ===
>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"
>

Re: S_L_U_A for worker MPM?

[Greg Ames]

Brian Pane wrote:

> I'm willing to spend some time this week on this issue, but first, can
> somebody clarify how prefork is handling the pipe-of-death?
> 
> It looks like prefork children only check the pod upon completion of
> a request.  Is that all there is to it, or am I missing something?

There has to be a way to unblock accept()s when a graceful restart happens in
order to get rid of the apr_poll.  I think prefork depends on the logic in
mpm_common.c::ap_mpm_pod_[signal|killpg] that sends dummy connects to do this in
situations where there's low/no traffic from the network. (disclaimer: haven't
studied the code recently)

btw, some of the workers_may_exit checks may not be necessary any more, so we
might be able to eliminate some conditional branches in the mainline path.  The
threaded MPM had the possibility of workers_may_exit getting set asynchronously
on thread x, and apparently we wanted thread y to know ASAP. (same disclaimer)

Greg

Re: Tagging 1.3.23

[Thomas Eibner]

On Mon, Jan 21, 2002 at 04:10:49PM -0500, Victor J. Orlikowski wrote:
> Problem found, but not resolved.
> 
> Turns out that find-dbm-lib in helpers looks for ndbm.h in
> /usr/include/db1 on RH 7.  This is provided in the db1-devel package.
> However, gdbm-devel also provides a ndbm.h, in /usr/include/gdbm.
> 
> The problem at hand: 
> We are going to have users who want to use mod_auth_dbm, and wonder
> why ndbm.h can't be found on their system when it's there, plain as
> day.
> 
> 2 solutions:
> 1) Doc it up. Does the job, but not what I want.
> 2) Fix find-dbm-lib properly, so that it does "The Right Thing" and
> uses whatever dbm it finds.
> 
> I prefer 2, but is it the right thing for 1.3.23 (I would hope that
> thsi would not scrap it)?
> 
> Issues: 
> Are there any GNU licensing issues with linking against gdbm? If so,
> solution 1 will do for now, since we will have to force the user to
> install db1-devel. However, find-dbm-lib has always felt like
> something of a hack to me. 

Moving around on the way that find-dbm-lib looks for the libs works for
me on my Debian box. Is this going to break something else?

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  



Index: find-dbm-lib
===
RCS file: /home/cvspublic/apache-1.3/src/helpers/find-dbm-lib,v
retrieving revision 1.12
diff -u -r1.12 find-dbm-lib
--- find-dbm-lib17 Jan 2002 13:20:51 -  1.12
+++ find-dbm-lib21 Jan 2002 21:44:42 -
@@ -13,9 +13,7 @@
*-linux*)
# many systems don't have -ldbm
DBM_LIB=""
-   if ./helpers/TestCompile lib dbm dbm_open; then
-   DBM_LIB="-ldbm"
-   elif ./helpers/TestCompile lib ndbm dbm_open; then
+   if ./helpers/TestCompile lib ndbm dbm_open; then
DBM_LIB="-lndbm"
if ./helpers/TestCompile lib db1 dbm_open; then
# Red Hat needs this; ndbm.h lives in db1
@@ -25,6 +23,8 @@
# For Red Hat 7, if not handled by the ndbm case above
DBM_LIB="-ldb1"
CFLAGS="$CFLAGS -I/usr/include/db1"
+   elif ./helpers/TestCompile lib dbm dbm_open; then
+   DBM_LIB="-ldbm"
fi
if [ "x$DBM_LIB" != "x" ]; then
LIBS="$LIBS $DBM_LIB"

Re: Tagging 1.3.23

[Bill Stoddard]

Interesting... Here are the first few lines from the tag...

C:\home\apache\apache-1.3\apache-1.3>cvs tag APACHE_1_3_23
cvs tag APACHE_1_3_23
? .cvsignore
cvs server: Tagging .
T ABOUT_APACHE
T Announcement


.cvsignore was, um, ignored it seems. It exists on my system...

Now it gets more interesting... Notice what happens when I do an update...

C:\home\apache\apache-1.3\apache-1.3>cvs update
cvs update
? .cvsignore
cvs server: Updating .
C .cvsignore
cvs update: move away ./.cvsignore; it is in the way
cvs server: Updating cgi-bin


I rm'ed .cvsignore, then updated it and the funky update message goes away. Curiouser 
and
curiouser...

Bill

- Original Message -
From: "Cliff Woolley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 21, 2002 4:13 PM
Subject: Re: Tagging 1.3.23


> On Mon, 21 Jan 2002, Bill Stoddard wrote:
>
> > in about 15 minutes...
>
> Any idea why apache-1.3/.cvsignore didn't get tagged?  I did a spot check
> of other files (including other .cvsignore's), and they seem okay.
>
> --Cliff
>
> --
>Cliff Woolley
>[EMAIL PROTECTED]
>Charlottesville, VA
>
>

Re: Tag 1.3.23?

[Greg Marr]

At 04:13 PM 01/21/2002, William Rowe wrote:
>The following (decorated, default) exported symbol names, and the 
>attached
>asm output from footest and footest2 illustrate that _stdcall is 
>ignored
>for vararg prototypes :)

looking up __stdcall in the MSVC help gives this:
The __stdcall calling convention is used to call Win32 API functions. 
The callee cleans the stack, so the compiler makes vararg functions 
__cdecl.

-- 
Greg Marr
[EMAIL PROTECTED]
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"

Re: Tag 1.3.23?

[William A. Rowe, Jr.]

From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Monday, January 21, 2002 9:44 AM


> Upon closer inspection, ap_rprintf() has been NON_STD for ages, so it's fine as is. 
>Not
> sure why it showed up on Rowe-san's list :-o


It went to _NONSTD in 1.302, and back to std in 1.309.

The tricky bit - it never picked up the discrepancy - and for that time 
http_protocol.h was actually in-sync.  I didn't add http_protocol.h 
to my list to backout because - it wasn't patched in the first place.
I didn't pick up that the .c and .h were out-of-sync, because my commit
normalized them, and never included http_protocol.h.

Now that we've discovered this doesn't cause incompatibility, we can
put them all in sync, if you like, to what MSVC actually compiled.

I've written (attached) a little footest to illustrate what the compiler
does with varargs, and compiled from c to asm, and it's very interesting.

The following (decorated, default) exported symbol names, and the attached 
asm output from footest and footest2 illustrate that _stdcall is ignored 
for vararg prototypes :)

fn_one_plus_export_cdecl
fn_one_plus_export_stdcall
fn_two_args_export_cdecl
_fn_two_args_export_stdcall@8

fn_one_plus_import_cdecl
fn_one_plus_import_stdcall
fn_two_args_import_cdecl
_fn_two_args_import_stdcall@8

To replicate;

cl footest.c footest2.c  will create you this example
cl -c -Fafootest.asm footest.c  creates you the asm dump

Bill




footest2.c
Description: Binary data


footest.c
Description: Binary data


footest2.asm
Description: Binary data


footest.asm
Description: Binary data

Re: Tagging 1.3.23

[Jim Jagielski]

+1

Rodent of Unusual Size wrote:
> 
> Thomas Eibner wrote:
> > 
> > On Mon, Jan 21, 2002 at 04:15:25PM -0500, Rodent of Unusual Size wrote:
> > >
> > > A /usr/include/gdbm/ndbm.h file exists.  Adding symbolic
> > > links all over the /usr/include tree is *not* an option if
> > > other packages don't have a problem with finding it.
> > 
> > But you're not including . You're including  in the
> > module.
> 
> I as a user am not doing either.  I am just building Apache.
> If it's including the wrong file (wrong because there *is*
> an ndbm.h file in the include tree), it's not *my* fault
> but Apache's.  Apache needs to include the correct file, not
> require me to put symbolic links all over my filesystem.
> -- 
> #ken  P-)}
> 
> Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
> Author, developer, opinionist  http://Apache-Server.Com/
> 
> "Millenium hand and shrimp!"
> 


-- 
===
   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"

Re: Tagging 1.3.23

[Rodent of Unusual Size]

Thomas Eibner wrote:
> 
> On Mon, Jan 21, 2002 at 04:15:25PM -0500, Rodent of Unusual Size wrote:
> >
> > A /usr/include/gdbm/ndbm.h file exists.  Adding symbolic
> > links all over the /usr/include tree is *not* an option if
> > other packages don't have a problem with finding it.
> 
> But you're not including . You're including  in the
> module.

I as a user am not doing either.  I am just building Apache.
If it's including the wrong file (wrong because there *is*
an ndbm.h file in the include tree), it's not *my* fault
but Apache's.  Apache needs to include the correct file, not
require me to put symbolic links all over my filesystem.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"Millenium hand and shrimp!"

Re: Tagging 1.3.23

[Jim Jagielski]

Victor J. Orlikowski wrote:
> 
> 2 solutions:
> 1) Doc it up. Does the job, but not what I want.
> 2) Fix find-dbm-lib properly, so that it does "The Right Thing" and
> uses whatever dbm it finds.
> 
> I prefer 2, but is it the right thing for 1.3.23 (I would hope that
> thsi would not scrap it)?

+1 on #2. Also, it should be smart enough to "associate" the
correct header with the correct library. We don't want to link
against gdbm but include db1's ndbm.h header :)

If this means a 1.3.24 (and since we're tagged, it almost
assuredly does) then it does. No biggie. :)

> 
> Issues: 
> Are there any GNU licensing issues with linking against gdbm? If so,
> solution 1 will do for now, since we will have to force the user to
> install db1-devel. However, find-dbm-lib has always felt like
> something of a hack to me. 
> 

Nope, no issue. We simply detect it and use it if required.
===
   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"

Re: Tagging 1.3.23

[Cliff Woolley]

On Mon, 21 Jan 2002, Bill Stoddard wrote:

> in about 15 minutes...

Any idea why apache-1.3/.cvsignore didn't get tagged?  I did a spot check
of other files (including other .cvsignore's), and they seem okay.

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA

Re: Tagging 1.3.23

[Rodent of Unusual Size]

Joe Orton wrote:
> 
> This will happen if you don't have the db1-devel package installed
> (unsurprisingly: if the header isn't there, it isn't detected). If you
> do have db1-devel installed, you should find -I/usr/include/db1 in your
> CFLAGS...

So what's the /usr/include/gdbm/ndbm.h file all about, then?
Meseems we should be more friendly about this at APACI ./configure
time, and removing mod_auth_dbm from the build list, rather than
horking on the 'missing' header file and aborting the make.  As far
as that goes, don't we have a means for modules to hook into
the ./configure process so they can complain if they're missing
prerequisites?
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"Millenium hand and shrimp!"

Re: Tagging 1.3.23

[Victor J. Orlikowski]

Problem found, but not resolved.

Turns out that find-dbm-lib in helpers looks for ndbm.h in
/usr/include/db1 on RH 7.  This is provided in the db1-devel package.
However, gdbm-devel also provides a ndbm.h, in /usr/include/gdbm.

The problem at hand: 
We are going to have users who want to use mod_auth_dbm, and wonder
why ndbm.h can't be found on their system when it's there, plain as
day.

2 solutions:
1) Doc it up. Does the job, but not what I want.
2) Fix find-dbm-lib properly, so that it does "The Right Thing" and
uses whatever dbm it finds.

I prefer 2, but is it the right thing for 1.3.23 (I would hope that
thsi would not scrap it)?

Issues: 
Are there any GNU licensing issues with linking against gdbm? If so,
solution 1 will do for now, since we will have to force the user to
install db1-devel. However, find-dbm-lib has always felt like
something of a hack to me. 

Victor
-- 
Victor J. Orlikowski   | The Wall is Down, But the Threat Remains!
==
[EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL PROTECTED]

Re: Tagging 1.3.23

[Jim Jagielski]

I have a feeling that this implies a 1.3.24... The real fix is
to include the correct header, or determine if it's even
needed.

Thomas Eibner wrote:
> 
> On Mon, Jan 21, 2002 at 03:53:31PM -0500, Rodent of Unusual Size wrote:
> > "Victor J. Orlikowski" wrote:
> > > 
> > > Argh
> > > Not this *again*.
> > > *Sigh*.
> > > Which linux distribution?
> > 
> > RH 7.1.  This was building for 1.3.22, so I'm pretty sure
> > this is something new.
> 
> I just tried it on my debian, with the ndbm.h symbolic link it works,
> without it breaks. So I'd say it's a linux problem. It's been happening
> to me for ages on my new debian boxen until I did the link from gdbm-ndbm.h
> 
> -- 
>   Thomas Eibner  DnsZone 
>   mod_pointer  
> 


-- 
===
   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"

Re: Tagging 1.3.23

[Thomas Eibner]

On Mon, Jan 21, 2002 at 04:15:25PM -0500, Rodent of Unusual Size wrote:
> Thomas Eibner wrote:
> > 
> > ln -s /usr/include/gdbm-ndbm.h /usr/include/ndbm.h in case
> > you're running debian and have installed libgdbmg1-dev.
> > (If that is the case: debian breakage by default, not apache's fault)
> 
> A /usr/include/gdbm/ndbm.h file exists.  Adding symbolic
> links all over the /usr/include tree is *not* an option if
> other packages don't have a problem with finding it.

But you're not including . You're including  in the
module.

And having -I/usr/include/gdbm sounds just as bad as linking with gdbm-ndbmh

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Re: Tagging 1.3.23

[Rodent of Unusual Size]

Thomas Eibner wrote:
> 
> ln -s /usr/include/gdbm-ndbm.h /usr/include/ndbm.h in case
> you're running debian and have installed libgdbmg1-dev.
> (If that is the case: debian breakage by default, not apache's fault)

A /usr/include/gdbm/ndbm.h file exists.  Adding symbolic
links all over the /usr/include tree is *not* an option if
other packages don't have a problem with finding it.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"Millenium hand and shrimp!"

S_L_U_A for worker MPM?

[Brian Pane]

One of the open items in the STATUS file is:

* Performance: Get the SINGLE_LISTEN_UNSERIALIZED_ACCEPT
  optimization working in worker.  prefork's new design for how
  to notice data on the pod should be sufficient.

I'm willing to spend some time this week on this issue, but first, can
somebody clarify how prefork is handling the pipe-of-death?

It looks like prefork children only check the pod upon completion of
a request.  Is that all there is to it, or am I missing something?

Thanks,
--Brian

Re: Tagging 1.3.23

[Joe Orton]

On Mon, Jan 21, 2002 at 03:10:36PM -0500, Ken Coar wrote:
>   :
> gcc -c  -I../../os/unix -I../../include   -DLINUX=22 -DNO_DBM_REWRITEMAP 
>-DUSE_HSREGEX -DUSE_EXPAT -I../../lib/expat-lite -g
> -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow  `../../apaci` -fpic 
>-DSHARED_MODULE mod_auth_dbm.c && mv
> mod_auth_dbm.o mod_auth_dbm.lo
> mod_auth_dbm.c:84:18: ndbm.h: No such file or directory

This will happen if you don't have the db1-devel package installed
(unsurprisingly: if the header isn't there, it isn't detected). If you
do have db1-devel installed, you should find -I/usr/include/db1 in your
CFLAGS...

joe

Re: WIN32 build

[sterling]

On Mon, 21 Jan 2002, Christian Gross wrote:

> I think it is great that all of the modules are dynamically loaded in the
> latest builds of Apache.  But there is a problem, in that the dependencies
> of libhttp.dll have not been altered.  Hence when building Apache not
> everything is built and then there are version conflicts, etc, etc.

What dependencies are missing?  When the magic number is updated you must
rebuild all modules -

> I update the dependencies, everytime I call a CVS update those changes are
> then wacked.  Is it possible to get the dependencies updated?  Thanks

why not submit a patch if you have the problem fixed?

sterling

Re: Tagging 1.3.23

[Thomas Eibner]

On Mon, Jan 21, 2002 at 03:53:31PM -0500, Rodent of Unusual Size wrote:
> "Victor J. Orlikowski" wrote:
> > 
> > Argh
> > Not this *again*.
> > *Sigh*.
> > Which linux distribution?
> 
> RH 7.1.  This was building for 1.3.22, so I'm pretty sure
> this is something new.

I just tried it on my debian, with the ndbm.h symbolic link it works,
without it breaks. So I'd say it's a linux problem. It's been happening
to me for ages on my new debian boxen until I did the link from gdbm-ndbm.h

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Re: Tagging 1.3.23

[Rodent of Unusual Size]

"Victor J. Orlikowski" wrote:
> 
> Argh
> Not this *again*.
> *Sigh*.
> Which linux distribution?

RH 7.1.  This was building for 1.3.22, so I'm pretty sure
this is something new.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"Millenium hand and shrimp!"

Re: Tagging 1.3.23

[Thomas Eibner]

On Mon, Jan 21, 2002 at 03:10:36PM -0500, Rodent of Unusual Size wrote:
> Bill Stoddard wrote:
> > 
> > Tagged.
> 
> Breakage:
> 
> CC="gcc" \
> CFLAGS="-g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow " \
> ./configure --enable-shared=max --enable-module=most
>   :
> make
>   :
> gcc -c  -I../../os/unix -I../../include   -DLINUX=22 -DNO_DBM_REWRITEMAP 
>-DUSE_HSREGEX -DUSE_EXPAT -I../../lib/expat-lite -g
> -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow  `../../apaci` -fpic 
>-DSHARED_MODULE mod_auth_dbm.c && mv
> mod_auth_dbm.o mod_auth_dbm.lo
> mod_auth_dbm.c:84:18: ndbm.h: No such file or directory
> make[4]: *** [mod_auth_dbm.so] Error 1
> make[3]: *** [all] Error 1
> make[2]: *** [subdirs] Error 1
> make[2]: Leaving directory `/home/coar/apache-1.3/src'
> make[1]: *** [build-std] Error 2
> make[1]: Leaving directory `/home/coar/apache-1.3'
> make: *** [build] Error 2

ln -s /usr/include/gdbm-ndbm.h /usr/include/ndbm.h in case you're running
debian and have installed libgdbmg1-dev. 
(If that is the case: debian breakage by default, not apache's fault)

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Re: cvs commit: apache-1.3/src/include http_protocol.h

[William A. Rowe, Jr.]

> wrowe   02/01/21 12:29:12
> 
>   Modified:src/include http_protocol.h
>   Log:
> ap_rprintf is implemented as API_EXPORT() in http_protocol.c.
> Therefore, make the prototype and implementation consistant.
>   
> The question remains, why no compiler warning/emit?  Because MSVC [my
> version, at least] must have changed all of the ap_fn(foo, ...) decl
> from _stdcall to _cdecl, on it's own!
>   
> I suggest our declarations are still borked, but they have worked only
> because MSVC ignored our poor judgement :)


I just proved this theory to myself by reapplying the .c patches without
reapplying the .h patches to make these fns _NONSTD.  No warning.  Changing
the return type for one of the ap_rprintf() declarations caused a prototype
mismatch warning - so we know the http_protocol.c really is reading the .h
prototypes.

I could commit the correct fixes or leave them alone.  I don't care at this
point.

Bill

Re: Tagging 1.3.23

[Victor J. Orlikowski]

Argh
Not this *again*.
*Sigh*.
Which linux distribution?

Victor
-- 
Victor J. Orlikowski   | The Wall is Down, But the Threat Remains!
==
[EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL PROTECTED]

Re: Tagging 1.3.23

[Rodent of Unusual Size]

Bill Stoddard wrote:
> 
> Tagged.

Breakage:

CC="gcc" \
CFLAGS="-g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow " \
./configure --enable-shared=max --enable-module=most
:
make
:
gcc -c  -I../../os/unix -I../../include   -DLINUX=22 -DNO_DBM_REWRITEMAP -DUSE_HSREGEX 
-DUSE_EXPAT -I../../lib/expat-lite -g
-O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow  `../../apaci` -fpic 
-DSHARED_MODULE mod_auth_dbm.c && mv
mod_auth_dbm.o mod_auth_dbm.lo
mod_auth_dbm.c:84:18: ndbm.h: No such file or directory
make[4]: *** [mod_auth_dbm.so] Error 1
make[3]: *** [all] Error 1
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/home/coar/apache-1.3/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/home/coar/apache-1.3'
make: *** [build] Error 2
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"Millenium hand and shrimp!"

Re: Tagging 1.3.23

[Bill Stoddard]

Tagged.

Jim,
Did you want to be RM? If so, take it away. If not, I'll try to roll the tarball 
tomorrow
morning.

Bill

- Original Message -
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 21, 2002 2:18 PM
Subject: Tagging 1.3.23


> in about 15 minutes...
>
> Bill
>

Tagging 1.3.23

[Bill Stoddard]

in about 15 minutes...

Bill

Re: WIN32 build

[William A. Rowe, Jr.]

Christian,

  libhttpd.dll runs without any modules.  Therefore it's isn't dependent
on them.

  There is a top-level InstallBin project that builds -all- modules.  This
came up once before.

  Does the list believe we need an 'intermediate' no-op BuildBin target
that will build all the files, without executing the InstallBin target?

Bill


- Original Message - 
From: "Christian Gross" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 21, 2002 11:10 AM
Subject: WIN32 build


> I think it is great that all of the modules are dynamically loaded in the 
> latest builds of Apache.  But there is a problem, in that the dependencies 
> of libhttp.dll have not been altered.  Hence when building Apache not 
> everything is built and then there are version conflicts, etc, etc.  While 
> I update the dependencies, everytime I call a CVS update those changes are 
> then wacked.  Is it possible to get the dependencies updated?  Thanks
> 
> Christian Gross
> 
> 
> 

WIN32 build

[Christian Gross]

I think it is great that all of the modules are dynamically loaded in the 
latest builds of Apache.  But there is a problem, in that the dependencies 
of libhttp.dll have not been altered.  Hence when building Apache not 
everything is built and then there are version conflicts, etc, etc.  While 
I update the dependencies, everytime I call a CVS update those changes are 
then wacked.  Is it possible to get the dependencies updated?  Thanks

Christian Gross

AddLanguage

[Zvi Har'El]

Hi Apache Developers,

Comparing the AddLanguage directives in the default configuration for Apache
1.3.22 and the most recent CVS version of Apache 2.0, I noticed some
differences. One, which is perhaps OK, is that the extension for Estonian files
has been changed from .ee to .et, so now the extension matches the ISO-693-2
language code (although this is not stirctly necessary, as the Danish example
shows). One which is *NOT OK*, is the omission of the line

AddLanguage he .he

which defines the extension for Hebrew files. I'll be very grateful if this
lines is put back in.

Thanks in advance,

Zvi.

-- 
Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics
tel:+972-54-227607   Technion - Israel Institute of Technology
fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL
"If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
   Monday, 9 Shevat 5762, 21 January 2002,  6:00PM

Re: Tag 1.3.23?

[Bill Stoddard]

Upon closer inspection, ap_rprintf() has been NON_STD for ages, so it's fine as is. Not
sure why it showed up on Rowe-san's list :-o

Bill

- Original Message -
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 21, 2002 10:37 AM
Subject: Re: Tag 1.3.23?


> Looks like ap_rprintf is still broken (or fixed in a way that is binary incompatable 
>:-)
> I'll fix this now...
>
> Bill
>
> > No, the original code was, simply, broken.  We must find a way to break
> > compatibility for modules using _those_few_functions_, alone.  They are;
> >
> > ap_snprintf
> ap.h - Ok
>
> > ap_table_do
> ap_alloc.h - Ok
>
> > ap_bvputs
> buff.h - Ok
>
> > ap_rprintf
> http_protocol.h - broken
>
> > ap_log_error
> http_log.h - OK
>
> > ap_log_rerror
> http_log.h - OK
>
> > ap_log_printf
>
> http_log.h - OK
>
>
>

Re: Tag 1.3.23?

[Bill Stoddard]

Looks like ap_rprintf is still broken (or fixed in a way that is binary incompatable 
:-)
I'll fix this now...

Bill

> No, the original code was, simply, broken.  We must find a way to break
> compatibility for modules using _those_few_functions_, alone.  They are;
>
> ap_snprintf
ap.h - Ok

> ap_table_do
ap_alloc.h - Ok

> ap_bvputs
buff.h - Ok

> ap_rprintf
http_protocol.h - broken

> ap_log_error
http_log.h - OK

> ap_log_rerror
http_log.h - OK

> ap_log_printf

http_log.h - OK

PHP Apache2Filter crashes on Win32

[Sebastian Bergmann]

  Here's a backtrace:

ap_save_brigade(ap_filter_t * 0x10d57628, apr_bucket_brigade * *
0x10d56004, apr_bucket_brigade * * 0x10a6fe74, apr_pool_t * 0x10d55b30)
line 418 + 49 bytes
php_output_filter(ap_filter_t * 0x10d57628, apr_bucket_brigade *
0x10d57790) line 350 + 32 bytes
ap_pass_brigade(ap_filter_t * 0x10d57628, apr_bucket_brigade * 0x10d57790)
line 390 + 16 bytes
default_handler(request_rec * 0x10d55b68) line 2974
ap_run_handler(request_rec * 0x10d55b68) line 186 + 78 bytes
ap_invoke_handler(request_rec * 0x10d55b68) line 359 + 9 bytes
ap_process_request(request_rec * 0x10d55b68) line 291 + 9 bytes
ap_process_http_connection(conn_rec * 0x10cdc140) line 280 + 9 bytes
ap_run_process_connection(conn_rec * 0x10cdc140) line 84 + 78 bytes
ap_process_connection(conn_rec * 0x10cdc140) line 232
worker_main(int 248) line 934
_threadstartex(void * 0x005f4688) line 212 + 13 bytes

  Latest CVS of both Apache2 and PHP 4.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

Re: [PATCH] 1.3: changing accept mutex for Cygwin

[Robert Collins]

===
- Original Message -
From: "Stipe Tolj" <[EMAIL PROTECTED]>
To: "Jeff Trawick" <[EMAIL PROTECTED]>
Cc: "Robert Collins" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>

> Ok, I'm going to send a new patch in for that.
>
> BTW, Robert, what about the pthread-win32 (native) library that has
> been of some use for Cygwin too. Maybe they have such cross-process
> mutexes included?!

I really can't speak for that project. Certainly they can't have support
for fork() - including pthread_atfork() and related calls. I'd be
surprised if they have cross-process mutex's, but you never know.

Rob