I was looking into cleaning up the inet_ntoa's in Apache, and in the process
also cleaned up some minute APR code. This just removes some magic #'s
It's so minor it is embarassing to post.. ;-)
Commit or reject at your leisure,
-- Jon
Index: lib/apr/include/apr_network_io.h
==
Jeff Trawick <[EMAIL PROTECTED]> writes:
> "David Reid" <[EMAIL PROTECTED]> writes:
>
> > Should we have a function in apr that can take an apr_sockaddr_t and return
> > a formatted address string? I mean we now need to deal with IPv4/IPv6 and
> > it'd be nice to abstract the need for different
On Fri, Dec 01, 2000 at 02:29:43PM -0800, [EMAIL PROTECTED] wrote:
>
> > > I think that is overkill for now. All of these flags are available in
> > > apr_private.h. If it starts to get unwieldy or something, then we can
> > > split.
> > > But let's start simple, make it harder when that is neede
> Not true. You can use the '-R' flag to CVS to make it a read-only
> non-locking checkout, or you can check it out via anoncvs.
Hmmm, never heard of that... I'll see if it works with ampersand modules.
Though I still think it would be better to just give everyone in httpd
access to apr. Lowers
Roy,
You are now in the avail file. I don't have access to put you in the
correct group, but I copied Manoj on this, so as soon as he puts you in
the correct group, you are good to go. Sorry about not giving you commit
access immediately, setting things up took a while, and I guess I missed
you
On Fri, 1 Dec 2000, Fielding, Roy wrote:
> > Not true. You can use the '-R' flag to CVS to make it a read-only
> > non-locking checkout, or you can check it out via anoncvs.
>
> Hmmm, never heard of that... I'll see if it works with ampersand modules.
> Though I still think it would be better to
> > Then please just leave it, and I'll implement the whole thing myself. The
> > other option is for you to implement it, and I'll go in immediately and
> > change it.
>
> Why is it that two people ask for the simple one, don't want to do the
> harder one (and don't want to see that complexity
On Fri, Dec 01, 2000 at 05:39:05PM -0800, [EMAIL PROTECTED] wrote:
> > > Unfortunately, after getting the normal code working I went into the
> > > WinNT MPM ('cause it too calls ap_new_connection()) and realized I
> > > needed to do some research about whether or not the APR socket (built
> > > vi
On Fri, Dec 01, 2000 at 05:27:06PM -0800, Brian Behlendorf wrote:
> On Fri, 1 Dec 2000, Fielding, Roy wrote:
> > > Not true. You can use the '-R' flag to CVS to make it a read-only
> > > non-locking checkout, or you can check it out via anoncvs.
> >
> > Hmmm, never heard of that... I'll see if it
> > Two questions. 1) Why the name change? 2) What particular OS object
> > are you talking about?
>
> 1) To signify that the object is be constructed/built with the OS object (an
>fd, socket fd, thread id, whatever), rather than simply inserted.
>
> 2) The case Jeff was running into was
> > True; my response was something of a knee-jerk to a request to change our
> > standard mode of operation (and expanding permissions to a much larger
> > group of people) due to what seemed to be a usage-related bug. Also if
> > the expectation for the future was that being in the "httpd" grou
> I know what the issue is we are trying to solve. So, are you suggesting
> that each APR type will have such an object? If we are only going to do
> this for sockets and locks (already doing it for socks), then I would
> prefer to just stick with apr_put_os_*. If we are going to do this for
>
On Fri, Dec 01, 2000 at 06:37:00PM -0800, [EMAIL PROTECTED] wrote:
> > I know what the issue is we are trying to solve. So, are you suggesting
> > that each APR type will have such an object? If we are only going to do
> > this for sockets and locks (already doing it for socks), then I would
> >
I was trying to compile apr on a powerpc-apple-beos machine, and ran
into the following quite strange error:
ake[1]: Entering directory `/boot/home/apr/lib'
cc -DBEOS -DBEOS -c -I../include -I../include/arch/beos apr_pools.c
### mwcc Compiler Error:
# return malloc(reqsize);
#
I looks like stdlib isn't being included, so the compiler is assuming that
malloc is defined as "int malloc(int)", but it has to return a void *, so
it is complaining. Could you look in apr_private.h, and ensure that
HAVE_STDLIB_H is being defined to be 1.
Thanks,
Ryan
On Fri, 1 Dec 2000, Sam
On Fri, Dec 01, 2000 at 08:13:30PM -0800, [EMAIL PROTECTED] wrote:
>
> I looks like stdlib isn't being included, so the compiler is assuming that
> malloc is defined as "int malloc(int)", but it has to return a void *, so
> it is complaining. Could you look in apr_private.h, and ensure that
> HAV
On Sat, Dec 02, 2000 at 01:28:36AM -0600, Sam TH wrote:
> On Fri, Dec 01, 2000 at 08:13:30PM -0800, [EMAIL PROTECTED] wrote:
> >
> > I looks like stdlib isn't being included, so the compiler is assuming that
> > malloc is defined as "int malloc(int)", but it has to return a void *, so
> > it is co
Sorry, got caught by the Reply All thing again and posted this to new-httpd
only...
david
> > > The reason we want both, is that they have different
> > > uses. In the perchild MPM, I really do want apr_put_os_socket,
because
> I
> > > don't have a full socket, I have a Unix Domain Socket, so I
On Sat, Dec 02, 2000 at 12:57:01AM -0800, Greg Stein wrote:
> That is generated by ./buildconf in the APR directory. It is created by
> autoconf or autoheader (I forget which). Something must have happened to it
> after you ran buildconf.
Thanks. My problem was not running buildconf. Too bad thi
Index: include/apr_network_io.h
===
RCS file: /home/cvs/apr/include/apr_network_io.h,v
retrieving revision 1.85
diff -u -r1.85 apr_network_io.h
--- include/apr_network_io.h 2000/12/01 18:47:28 1.85
+++ include/apr_network_io.h 20
This patch is Big-Time Bad Busted (double-space, no indents). Try again? :-)
Cheers,
-g
On Sat, Dec 02, 2000 at 11:12:37AM -, David Reid wrote:
> Index: include/apr_network_io.h
>
> ===
>
> RCS file: /home/cvs/apr/include/apr_n
On Sat, Dec 02, 2000 at 04:51:46AM -0600, Sam TH wrote:
> On Sat, Dec 02, 2000 at 12:57:01AM -0800, Greg Stein wrote:
> > That is generated by ./buildconf in the APR directory. It is created by
> > autoconf or autoheader (I forget which). Something must have happened to it
> > after you ran buildco
On Sat, Dec 02, 2000 at 03:38:02AM -0800, Greg Stein wrote:
> I would think that configure would barf when it tries to use
> apr_private.h.in, but I could easily imagine that it got buried in some
> output and just wasn't easily seen. It wouldn't be hard to add a test, but
> it is important to rec
On Sat, Dec 02, 2000 at 03:38:02AM -0800, Greg Stein wrote:
> users don't need the autoconf tool). IOW, the right answer is to expect the
> developers to know, or to have a README.dev or something.
Attached is just such a README.dev file.
sam th
[EMAIL
On Sat, Dec 02, 2000 at 07:33:39AM -0600, Sam TH wrote:
> On Sat, Dec 02, 2000 at 03:38:02AM -0800, Greg Stein wrote:
> > users don't need the autoconf tool). IOW, the right answer is to expect the
> > developers to know, or to have a README.dev or something.
>
> Attached is just such a README.dev
On Sat, Dec 02, 2000 at 04:13:51PM -, [EMAIL PROTECTED] wrote:
> gstein 00/12/02 08:13:50
>
> Added: ..cvsignore Makefile.in STATUS buildconf.sh
> configure.in
>build.cvsignore Makefile.in install-sh rules.mk.in
>
> On Sat, Dec 02, 2000 at 12:57:01AM -0800, Greg Stein wrote:
> > That is generated by ./buildconf in the APR directory. It is created by
> > autoconf or autoheader (I forget which). Something must have happened to it
> > after you ran buildconf.
>
> Thanks. My problem was not running buildconf.
> Note that it uses autoconf and libtool. It isn't complicated enough for
> automake, so I didn't bother. The build stuff is also greatly simplified
> over those in APR and Apache. A single build/rules.mk and teeny makefiles
> throughout.
I would really prefer to not use libtool. This is meant t
On Sat, Dec 02, 2000 at 09:04:27AM -0800, [EMAIL PROTECTED] wrote:
>
> > On Sat, Dec 02, 2000 at 12:57:01AM -0800, Greg Stein wrote:
> > > That is generated by ./buildconf in the APR directory. It is created by
> > > autoconf or autoheader (I forget which). Something must have happened to
> > > i
On Sat, Dec 02, 2000 at 07:07:59PM -, David Reid wrote:
> Sam,
>
> Now I'm really confused. You shouldn't be getting these errors if there
> isn't a networkio.h file in your beos directories. Can you make sure that
> you don't have a networkio.h in ANY beos directory that's referenced, i.e.
What platform are you trying to build on? And what is the problem you're
seeing?
All of my testing was on Linux, and it worked like a charm (before/after the
change below). So... I'm wondering what part isn't working for you?
Cheers,
-g
On Sat, Dec 02, 2000 at 05:42:39PM -, [EMAIL PROTECTED]
On Sat, Dec 02, 2000 at 09:18:12AM -0800, [EMAIL PROTECTED] wrote:
> > Note that it uses autoconf and libtool. It isn't complicated enough for
> > automake, so I didn't bother. The build stuff is also greatly simplified
> > over those in APR and Apache. A single build/rules.mk and teeny makefiles
>
On Sat, Dec 02, 2000 at 09:18:12AM -0800, [EMAIL PROTECTED] wrote:
>...
> > The big step, of course, is deciding how we'll move files from other
> > repositories, then going and doing it. Here are the move options, let's see
> > some voting:
> >
> > 1) copy the ,v files then remove tags on the new
On Sat, 2 Dec 2000, Greg Stein wrote:
> What platform are you trying to build on? And what is the problem you're
> seeing?
>
> All of my testing was on Linux, and it worked like a charm (before/after the
> change below). So... I'm wondering what part isn't working for you?
I'm on Linux, and SUBD
> > > The big step, of course, is deciding how we'll move files from other
> > > repositories, then going and doing it. Here are the move options, let's
> > > see
> > > some voting:
> > >
> > > 1) copy the ,v files then remove tags on the new files.
> > > 2) "cvs add" the head of the old file wi
On Sat, Dec 02, 2000 at 02:01:57PM -0800, [EMAIL PROTECTED] wrote:
>
> > > > The big step, of course, is deciding how we'll move files from other
> > > > repositories, then going and doing it. Here are the move options, let's
> > > > see
> > > > some voting:
> > > >
> > > > 1) copy the ,v files
On Sat, Dec 02, 2000 at 02:00:40PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 2 Dec 2000, Greg Stein wrote:
>
> > What platform are you trying to build on? And what is the problem you're
> > seeing?
> >
> > All of my testing was on Linux, and it worked like a charm (before/after the
> > change bel
> > > Note that it uses autoconf and libtool. It isn't complicated enough for
> > > automake, so I didn't bother. The build stuff is also greatly simplified
> > > over those in APR and Apache. A single build/rules.mk and teeny makefiles
> > > throughout.
> >
> > I would really prefer to not use li
On Sat, Dec 02, 2000 at 02:09:29PM -0800, [EMAIL PROTECTED] wrote:
>...
> > Well, unlike Apache, we need to be able to create a shared library for
> > consumption by other programs. (Apache only needs dynamic-load modules) To
> > build a shared library, libtool is the best available option.
> >
>
After I checked in the stuff last night, I realized that "apu_config.h" was
probably using the "wrong" prefix.
Does anybody have a good idea for what prefix we *do* want to use?
Maybe "aul" for "Apache Utility Library"? Continue with "apu" for "APache
Utilities [library]"?
Others?
Note that Apa
> After I checked in the stuff last night, I realized that "apu_config.h" was
> probably using the "wrong" prefix.
I would suggest we just use APR. This is the APR utility library, and it
makes sense in my mind to use the same prefix.
> Note that Apache 2.0 will need to include a header in src/
On Sat, Dec 02, 2000 at 02:36:35PM -0800, [EMAIL PROTECTED] wrote:
>
> > After I checked in the stuff last night, I realized that "apu_config.h" was
> > probably using the "wrong" prefix.
>
> I would suggest we just use APR. This is the APR utility library, and it
> makes sense in my mind to use
> > > After I checked in the stuff last night, I realized that "apu_config.h"
> > > was
> > > probably using the "wrong" prefix.
> >
> > I would suggest we just use APR. This is the APR utility library, and it
> > makes sense in my mind to use the same prefix.
>
> Hmm. We would then need to co
> > The problem is that a libtool .so file, AFAIK, is not the same as a
> > regular .so file.
>
> It is the same as a .so file:
>
> [EMAIL PROTECTED] apr-util]$ file .libs/libaprutil.so.0.0.0
> .libs/libaprutil.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version
> 1, not stripped
> [EM
> Dang. That is just wonky. I've got RedHat 6.1 installed. The relevant
> packages are:
>
> make-3.77-6
> bash-1.14.7-16
> autoconf-2.13-5
> libtool-1.3.4-3
>
> What do you have?
mandrake 7.1
Autoconf version 2.14.1
ltmain.sh (GNU libtool) 1.3.5 (1.385.2.206 2000/05/27 11:12:27)
I woul
On Sat, Dec 02, 2000 at 02:59:03PM -0800, [EMAIL PROTECTED] wrote:
>...
> > Nope. The .so files are standard .so files. Anybody can use and link against
> > them, just like every other .so file.
>
> Okay, my comments came from reading the libtool manual,
Hey... nobody can dis you for reading the
On Sat, Dec 02, 2000 at 02:58:15PM -0800, [EMAIL PROTECTED] wrote:
> > > > After I checked in the stuff last night, I realized that "apu_config.h"
> > > > was
> > > > probably using the "wrong" prefix.
> > >
> > > I would suggest we just use APR. This is the APR utility library, and it
> > > mak
On Sat, Dec 02, 2000 at 03:00:26PM -0800, [EMAIL PROTECTED] wrote:
> > Dang. That is just wonky. I've got RedHat 6.1 installed. The relevant
> > packages are:
> >
> > make-3.77-6
> > bash-1.14.7-16
> > autoconf-2.13-5
> > libtool-1.3.4-3
> >
> > What do you have?
>
> mandrake 7.1
> Autoc
Sam TH <[EMAIL PROTECTED]> writes:
> Then I encounter this error:
>
> cc -DBEOS -DBEOS -c -I../../include -Imm shmem.c
> ### mwcc Compiler Error:
> # MM *newmm = mm_create(reqsize + sizeof(*newmm), file,
> MM_ALLOCATE_ENOUGH);
> # ^
> # il
> > > What do you have?
> >
> > mandrake 7.1
> > Autoconf version 2.14.1
> > ltmain.sh (GNU libtool) 1.3.5 (1.385.2.206 2000/05/27 11:12:27)
> >
> > I would have to dig to get my bash version.
>
> Mandrake is rpm-based:
>
> $ rpm -q make bash
>
> I think the make version might actually be the
> Yep... this bug crept in last night; it showed up in a gcc warning on
> FreeBSD in the wee hours... sizeof(* void *) is undefined.
>
> You can't do
>
> void *x;
> sizeof(*x)
ARGH! This is my fault. It compiled cleanly on my Linux box. I'll try
to get to it today unless somebody beats
On Sat, Dec 02, 2000 at 03:42:52PM -0800, [EMAIL PROTECTED] wrote:
> > > > What do you have?
> > >
> > > mandrake 7.1
> > > Autoconf version 2.14.1
> > > ltmain.sh (GNU libtool) 1.3.5 (1.385.2.206 2000/05/27 11:12:27)
> > >
> > > I would have to dig to get my bash version.
> >
> > Mandrake is rp
52 matches
Mail list logo
