APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2002/05/31 00:07:40 $]
Release:
0.9.0-dev : in progress
2.0a9 : released December 12, 2000
2.0a8 : released November 20, 2000
2.0a7 : released October 8, 2000
2.0a6 :
APRUTIL LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2002/05/31 00:13:52 $]
Release:
0.9.0-dev : in progress
2.0a9 : released December 12, 2000
RELEASE SHOWSTOPPERS:
* Need apu_compat.h to track the latest renames
Status:
Well, I did it today. Plugged in libapr tagged APACHE_2_0_39 into an
APACHE_2_0_35 and APACHE_2_0_36 libaprutil + httpd. Of course
we changed the bucket semantics and behavior too much to actually bring
libaprutil up to the 2.0.39 rev. This was a plug-in, binary compatibility
experiment.
And
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
Sent: 27 June 2002 06:03
Hi,
Well, I did it today. Plugged in libapr tagged APACHE_2_0_39 into an
APACHE_2_0_35 and APACHE_2_0_36 libaprutil + httpd. Of course
we changed the bucket semantics and behavior too much to actually bring
On Thu, Jun 27, 2002 at 09:42:12AM +0200, Sander Striker wrote:
The options on this are:
snip, snip, snip
Thoughts?
5) Do nothing as APR isn't released yet.
Personally, I don't care about backwards compatibility until
we hit 1.0 of APR. However, the fact that so much of APR has
stayed the
* Justin Erenkrantz ([EMAIL PROTECTED]) wrote :
On Thu, Jun 27, 2002 at 09:42:12AM +0200, Sander Striker wrote:
The options on this are:
snip, snip, snip
Thoughts?
5) Do nothing as APR isn't released yet.
Personally, I don't care about backwards compatibility until
we hit 1.0 of
Brian Behlendorf wrote:
I'll be rebooting daedalus and icarus again soon to pick up a fix for
this.
What a week.
...and it ain't over yet :-(
Looks like we picked up a FreeBSD 4.6 kernel patch to sendfile() which changes
its API, and causes asserts in sendfile_it_all to pop frequently.
At 02:42 AM 6/27/2002, Sander Striker wrote:
The offending file is include/apr_allocator.h, a relative youngster,
introduced
on 15 march 2002.
I ment to back up and retitle the post ... thanks for pointing that out...
85 apr_memnode_t *next;
86 striker 1.6 apr_memnode_t
Andi Gutmans wrote:
I read the reaps article. I didn't quite understand how they actually
code their heaps and therefore it's hard to understand how fast it
really is.
My approach is actually similar to theirs (pools with free) and they
even mention this kind of approach. I created pools which
'just wondering if somebody could spend 5 seconds to give a thought to it
:-).
-Madhu
-Original Message-
From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 26, 2002 9:35 AM
To: 'dev@apr.apache.org'
Subject: [PATCH] Regarding semun definition in
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) [EMAIL PROTECTED] writes:
'just wondering if somebody could spend 5 seconds to give a thought to it
:-).
yes, this is an good fix (but you knew that already)... I'll commit
later today if nobody beats me to it (staring down gun barrels at the
moment)
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) [EMAIL PROTECTED] writes:
On platforms where the semun union is not available, the APR defines the
semun structure - but I believe the first parameter should be a int val
and not long val. I verified it on HP-UX and Linux (both 32-bit and 64-bit
On 27 Jun 2002, Jeff Trawick wrote:
So I guess sizeof(long) is 8 bytes on 64-bit HP-UX? sizeof(long) is
still 4 on 64-bit AIX.
$ uname -a
HP-UX nova126 B.11.00 U 9000/785 2010844465 unlimited-user license
$ cat test.c
#include stdio.h
int main()
{
Jeff Trawick wrote:
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) [EMAIL PROTECTED] writes:
On platforms where the semun union is not available, the APR defines the
semun structure - but I believe the first parameter should be a int val
and not long val. I verified it on HP-UX and Linux
Yep - with HP-UX running on 64-bit Itanium, and using the 64-bit data model.
The side effect of having the long val in the union definition is that
it'll have corrupted the mutex/semaphore while creating the proc_mutex
itself (proc_mutex_sysv_create). On HP-UX, the symptom was that the
Yep. we compile with the +DD64 option for ansi-c.
-Madhu
-Original Message-
From: Cliff Woolley [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 27, 2002 10:49 AM
To: Jeff Trawick
Cc: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1); 'dev@apr.apache.org'
Subject: Re: [PATCH] Regarding semun
At 01:00 PM 6/27/2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
Yep - with HP-UX running on 64-bit Itanium, and using the 64-bit data model.
The side effect of having the long val in the union definition is that
it'll have corrupted the mutex/semaphore while creating the proc_mutex
itself
Jim Jagielski [EMAIL PROTECTED] writes:
Jeff Trawick wrote:
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) [EMAIL PROTECTED] writes:
On platforms where the semun union is not available, the APR defines the
semun structure - but I believe the first parameter should be a int val
and not
I'm still slogging through tons of email, but was the issue that
it was simply 'long' instead of 'int' (and trusting that the platform/OS
correctly handles things) or that we require a specific physical
size?
FWIW, the current 2.0 implementation is copied from 1.3, so if it's
wrong in one, it's
At 02:17 PM 6/27/2002, Jim Jagielski wrote:
I'm still slogging through tons of email, but was the issue that
it was simply 'long' instead of 'int' (and trusting that the platform/OS
correctly handles things) or that we require a specific physical
size?
Ours is simply a HANDLE. End of issue for
Jeff Trawick [EMAIL PROTECTED] writes:
The header file defines in apr_private.h are busted and APR won't
build. Here is a glaring example:
/* Define if you have the string.h header file. */
/* #undef HAVE_STRING_H */
config.cache seems to have the right value:
Justin Erenkrantz [EMAIL PROTECTED] writes:
I tried installing local copies of GNU m4 and autoconf 2.13, but the
problem persists. I even tried specifying /usr/local/bin/bash instead
of /bin/sh in configure. Any other ideas to narrow down what broke
it?
By chance, do you have
Jeff Trawick [EMAIL PROTECTED] writes:
Justin Erenkrantz [EMAIL PROTECTED] writes:
I tried installing local copies of GNU m4 and autoconf 2.13, but the
problem persists. I even tried specifying /usr/local/bin/bash instead
of /bin/sh in configure. Any other ideas to narrow down what
On Thu, Jun 27, 2002 at 06:17:41PM -0400, Jeff Trawick wrote:
talk about PRs coming our way for people upgrading FreeBSD... first,
old builds are suddenly unreliable, and new builds are impossible
without switching to GNU sed!
is this on a fairly recent freebsd -STABLE system? if so,
Garrett Rooney [EMAIL PROTECTED] writes:
On Thu, Jun 27, 2002 at 06:17:41PM -0400, Jeff Trawick wrote:
talk about PRs coming our way for people upgrading FreeBSD... first,
old builds are suddenly unreliable, and new builds are impossible
without switching to GNU sed!
is this on a
On Thu, Jun 27, 2002 at 06:53:16PM -0400, Jeff Trawick wrote:
Garrett Rooney [EMAIL PROTECTED] writes:
On Thu, Jun 27, 2002 at 06:17:41PM -0400, Jeff Trawick wrote:
talk about PRs coming our way for people upgrading FreeBSD... first,
old builds are suddenly unreliable, and new
26 matches
Mail list logo
