1.3b1 bug in making support/htdigest.c

[Manoj Kasichainula <ma...@io.com>]

Dunno if these should go to the bug database if the version isn't
released...

"make support" in the src directory (and because of this, make in the
root directory) fails because of a compilation error in htdigest.c
under Red Hat Linux 4.2. ../main/md5.c is included, and it refers to
os.h.  But src/os/unix isn't -I'ed when building the support stuff.

I don't know how to fix this The Right Way(TM), but I'll probably try
to become conversant with Configure this evening so I can fix this in
the support Makefile if someone else doesn't.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"I mean how can a punk be cyber?" - Bruce Sterling

Re: 1.3b1 bug in making support/htdigest.c

[Dean Gaudet <dg...@arctic.org>]

On Wed, 15 Oct 1997, Manoj Kasichainula wrote:

> On Sun, Oct 12, 1997 at 05:04:41PM -0700, Dean Gaudet wrote:
> > The solution, which we've talked about, is to make a libap directory
> > containing these things (and other things like most of everything in
> > util.c).  We can start off with the easy stuff that doesn't require
> > alloc.c -- that's most of the portability stuff anyhow. 
> 
> I'd like to give this a crack, as sort of an intro to how things work
> in the code. Would this basically be all of the ap_* functions?

Ideally it'd be all the ap_* functions and macros.  Unfortunately in
practice conf.h makes things messy.  So to start with it should be
ap_signal (well, actually, signal() from http_main), and probably the
handful of things like strcasecmp, etc. from util.c which are generic
portability functions.  You could move util_snprintf.c and fnmatch.c to
the libap directory as well.

If anything needs to be changed then it's probably not a good idea to do
it now, so ask.  Just moving where things are compiled shouldn't be an
issue though.

> BTW, any good documents or good starting points for learning about the
> code. Is it worth the trouble at this point, or should I wait until
> development on 2.0 starts?

IMHO it's worth learning 1.3 as well ... 'cause we can always use the
extra eyes/hands.  A word of warning, when you do post a patch, we
sometimes take forever to act on it, you may need to repost it a week or
two later... we're just slow (or busy with our real jobs is more like it). 
We're in feature freeze as you probably know, but there's a lot of open
bugs to be dealt with. 

Dean

Re: 1.3b1 bug in making support/htdigest.c

[Manoj Kasichainula <ma...@io.com>]

On Sun, Oct 12, 1997 at 05:04:41PM -0700, Dean Gaudet wrote:
> The solution, which we've talked about, is to make a libap directory
> containing these things (and other things like most of everything in
> util.c).  We can start off with the easy stuff that doesn't require
> alloc.c -- that's most of the portability stuff anyhow. 

I'd like to give this a crack, as sort of an intro to how things work
in the code. Would this basically be all of the ap_* functions?

BTW, any good documents or good starting points for learning about the
code. Is it worth the trouble at this point, or should I wait until
development on 2.0 starts?

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Very sad life. Probably have very sad death. But at least these is
symmetry." - Zathras in _Babylon 5_

Re: 1.3b1 bug in making support/htdigest.c

[Dean Gaudet <dg...@arctic.org>]

On Sun, 12 Oct 1997, Manoj Kasichainula wrote:

> On Sun, Oct 12, 1997 at 03:42:36PM -0700, Dean Gaudet wrote:
> > I fixed this in the repository yesterday ... support/Makefile.tmpl needs
> > INCLUDES_DEPTH1 added to INCLUDES. 
> 
> I made the same change in the patch I was about to post. But, I also
> had a problem with the ap_signal definition in conf.h. I couldn't find
> ap_signal anywhere in the code, so I deleted the definition when
> compiling everything. Is this correct?

Ugh I thought this known problem was solved... but I guess it wasn't. 
ap_signal isn't defined explicitly, but you'll find code for signal() in
http_main ... and since there's a "#define signal ap_signal" in conf.h
that def'n in http_main is really ap_signal.

The solution, which we've talked about, is to make a libap directory
containing these things (and other things like most of everything in
util.c).  We can start off with the easy stuff that doesn't require
alloc.c -- that's most of the portability stuff anyhow. 

Jim, others, how would you feel about this being fixed during 1.3b(n+1),
n=1 or 2? I don't have the time to do it, but maybe someone else does.  It
should just be the easy stuff for now -- moving functions from one file to
another and modifying the makefiles appropriately.  We can get into moving
other things (like alloc) into libap after 1.3. 

> BTW, are the cvs mailing-list archives supposed to be consistently
> up-to-date? I grabbed the file from
> ftp://dev.apache.org/httpd/mail/cvs.9710, and although it was modified
> today, it only lists entries up to October 8th.

They're supposed to be, but got messed up during the machine upgrade. 

Dean

Re: 1.3b1 bug in making support/htdigest.c

[Manoj Kasichainula <ma...@io.com>]

On Sun, Oct 12, 1997 at 03:42:36PM -0700, Dean Gaudet wrote:
> I fixed this in the repository yesterday ... support/Makefile.tmpl needs
> INCLUDES_DEPTH1 added to INCLUDES. 

I made the same change in the patch I was about to post. But, I also
had a problem with the ap_signal definition in conf.h. I couldn't find
ap_signal anywhere in the code, so I deleted the definition when
compiling everything. Is this correct?

BTW, are the cvs mailing-list archives supposed to be consistently
up-to-date? I grabbed the file from
ftp://dev.apache.org/httpd/mail/cvs.9710, and although it was modified
today, it only lists entries up to October 8th.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Hypocrisy is the greatest luxury." - Disposable Heroes of Hiphoprisy