On 17/9/02 0:13, "Greg Stein" <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 16, 2002 at 06:00:20PM -0500, Ben Collins-Sussman wrote:
>> [EMAIL PROTECTED] writes:
>>
>>> Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
>>> which allows you to continue to do -lapr. Is there a reaso
It isn't directly related to autoconf. We wanted to share autoconf and
other
build scripts. That is the *core* reason why the projects are not
self-supporting.
Not only share them -- we wanted to avoid running them 5 times for each
build of httpd. We only need to run them once and share the resul
On Mon, Sep 16, 2002 at 06:00:20PM -0500, Ben Collins-Sussman wrote:
> [EMAIL PROTECTED] writes:
>
> > Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
> > which allows you to continue to do -lapr. Is there a reason we chose to
> > do something different???
>
> Subversion sw
[EMAIL PROTECTED] writes:
> Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
> which allows you to continue to do -lapr. Is there a reason we chose to
> do something different???
Subversion switched to naming our many libraries "libsvn_foo-1.so"
last June, based on this rati
On 16/9/02 23:54, "Sander Striker" <[EMAIL PROTECTED]> wrote:
>> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
>> Sent: 17 September 2002 00:36
>
>> On 16/9/02 23:15, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
> Sent: 17 September 2002 00:36
> On 16/9/02 23:15, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> >
> > Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
> > which allows you to continue to do -lapr. Is there a reason we
On 16/9/02 23:15, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
> which allows you to continue to do -lapr. Is there a reason we chose to
> do something different???
Sgrunf Whatchasaying Ryan?
$ ls -1a /opt/apache/l
Why did we choose libapr-#.so? Most other libraries use libapr.so.#,
which allows you to continue to do -lapr. Is there a reason we chose to
do something different???
Ryan
___
Ryan Bloom [
Aaron Bannert wrote:
On Thu, Aug 22, 2002 at 03:59:24PM -0400, Chris Darroch wrote:
[snip]
The proc_mutex_proc_pthread_acquire() function seems to
suck up the EOWNERDEAD return value, setting the curr_locked flag
to 1 and returning APR_SUCCESS, so that's what I made the tryacquire
case do also.
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
> Sent: 16 September 2002 22:50
> G:\clean\httpd-2.0.41\srclib\apr\memory\unix\apr_pools.c(615) : warning
> C4018: '<' : signed/unsigned mismatch
> G:\clean\httpd-2.0.41\srclib\apr\memory\unix\apr_pools.c(623) : warning
> C4018: '<' : signed
G:\clean\httpd-2.0.41\srclib\apr\memory\unix\apr_pools.c(615) : warning C4018:
'<' : signed/unsigned mismatch
G:\clean\httpd-2.0.41\srclib\apr\memory\unix\apr_pools.c(623) : warning C4018:
'<' : signed/unsigned mismatch
G:\clean\httpd-2.0.41\srclib\apr\memory\unix\apr_pools.c(928) : warning C4018
Jeff Trawick wrote:
What will happen if keys and values in b are NOT from an ancestor of
a's pool but b has sufficient lifetime?
I'm debugging a segfault in hash_overlap() when driven by a 3rd party
Apache module. Clearly the 3rd party module is misusing
apr_table_overlap() because a is from the r
What will happen if keys and values in b are NOT from an ancestor of
a's pool but b has sufficient lifetime?
I'm debugging a segfault in hash_overlap() when driven by a 3rd party
Apache module. Clearly the 3rd party module is misusing
apr_table_overlap() because a is from the request pool and b i
On Mon, 16 Sep 2002, Greg Stein wrote:
> If for some godawful procedural non-purpose, you don't want to accept
> the contents of that file.
The reason for asking explitly for nominees now is that I could not find
anything like a 'deadline' or some other discriminatory element in the
past posting
On Mon, Sep 16, 2002 at 12:55:44PM +0200, Dirk-Willem van Gulik wrote:
>...
> Nominations are made by posting to dev@apr.apache.org and Cc:
> [EMAIL PROTECTED] Ideally it should include a short note on the
> candidature.
There is already a set of nominations and (accepted) volunteers in
apr-core/S
> From: Dirk-Willem van Gulik [mailto:[EMAIL PROTECTED]
> Sent: 16 September 2002 12:56
> [EMAIL PROTECTED] Brian Pane
> [EMAIL PROTECTED] Brian Pane
Brian Pane is listed twice. This may be a cut 'n paste error, or
an error in the records this was pasted from.
> [EMAIL PROTECTED]
The following people currently have commit access on one or more apr-*
repositories and/or belong to the unix group apr on cvs.apache.org.
It is there fore assumed that they are as committers entitled to vote.
Please verify this list for us; and let us know.
-> Anyone who should be on here
Call for nominations for the Chair of the APR PMC.
The voting volunteers are ready to receive your nominations :-) Note that
the cutoff date is 2002-9-22.
You can either nominate yourself or you can nominate someone else.
What counts is that the confirmation from the nominee him/herself is
rece
Folks,
The APR PMC Chair, Ryan Bloom, has indicated that he wants to step down.
Hence elections are needed.
Logistics for those elections (v1.05)
All communication from here will be ONLY on:
dev@apr.apache.org
and for the committers copied on:
@apache.org
So make sure you ar
19 matches
Mail list logo
