Re: proposed fix for funky Apache binbuild "issue"

2002-04-15 Thread Albert Chin
On Mon, Apr 15, 2002 at 03:23:00PM -0400, Jeff Trawick wrote: > Albert Chin <[EMAIL PROTECTED]> writes: > > > > But there is a problem with this: LD_LIBRARY_PATH is always searched > > > after the etched-in path. Also, the etched-in path is searched before > > > the system path. > > > > Accordin

Re: proposed fix for funky Apache binbuild "issue"

2002-04-15 Thread Jeff Trawick
Albert Chin <[EMAIL PROTECTED]> writes: > > But there is a problem with this: LD_LIBRARY_PATH is always searched > > after the etched-in path. Also, the etched-in path is searched before > > the system path. > > According to ld.so.1(1) on Solaris 8/SPARC: > The runtime linker uses a prescri

Re: proposed fix for funky Apache binbuild "issue"

2002-04-15 Thread Albert Chin
On Mon, Apr 15, 2002 at 10:47:34AM -0400, Jeff Trawick wrote: > For Apache binary distributions, an environment variable (e.g., > LD_LIBRARY_PATH) is used at run-time to locate libapr, libaprutil, > libexpat, etc. because the path etched into the httpd executable is > the path used when creating th

APR's configure

2002-04-15 Thread Jim Jagielski
I've been trying to track down the problem Jeff reported on Darwin when using autoconf 2.52 and have found something weird... In some cases, the apr configure script has a large section added in at the front from the apr/build/libtool.m4 code. It does stuff like checking PATH_SEPARATOR and echo and

Re: [PATCH] Re: the most common seg fault on daedalus

2002-04-15 Thread Cliff Woolley
On Mon, 15 Apr 2002, Brian Pane wrote: > I like Justin's suggestion: a generic function that removes all cleanups > registered for a given object. > > In fact, we could even do this by overloading apr_pool_cleanup_kill() to > allow NULL as the cleanup pointer, where NULL means "unregister all clea

Re: [PATCH] Re: the most common seg fault on daedalus

2002-04-15 Thread Cliff Woolley
On 15 Apr 2002, Jeff Trawick wrote: > I know; I didn't want to clutter the attempt to find the right > solution with such details :) Oh. Oops. :) > I'm having a hard time thinking of a reasonable way to expose enough > information so that the cleanup can be killed. Some ugly helper > function

Re: [PATCH] Re: the most common seg fault on daedalus

2002-04-15 Thread Brian Pane
Jeff Trawick wrote: Cliff Woolley <[EMAIL PROTECTED]> writes: On 15 Apr 2002, Jeff Trawick wrote: What happens if we kill the cleanup on the apr_mmap_t when we create an mmap bucket? That would work [and would be the preferable solution as far as I'm concerned], but there's currently no API to do i

Re: [PATCH] Re: the most common seg fault on daedalus

2002-04-15 Thread Jeff Trawick
Cliff Woolley <[EMAIL PROTECTED]> writes: > On 15 Apr 2002, Jeff Trawick wrote: > > > What happens if we kill the cleanup on the apr_mmap_t when we create > > an mmap bucket? > > That would work [and would be the preferable solution as far as I'm > concerned], but there's currently no API to do

Re: [PATCH] Re: the most common seg fault on daedalus

2002-04-15 Thread Justin Erenkrantz
On Mon, Apr 15, 2002 at 01:15:50PM -0400, Jeff Trawick wrote: > What happens if we kill the cleanup on the apr_mmap_t when we create > an mmap bucket? FWIW, this is exactly the solution I mentioned to Cliff on IRC. I think we need some way to kill *all* cleanups related to a data variable? Perha

Re: [PATCH] Re: the most common seg fault on daedalus

2002-04-15 Thread Cliff Woolley
On 15 Apr 2002, Jeff Trawick wrote: > What happens if we kill the cleanup on the apr_mmap_t when we create > an mmap bucket? That would work [and would be the preferable solution as far as I'm concerned], but there's currently no API to do it with. To kill the cleanup, you need access to the cle

Re: [PATCH] Re: the most common seg fault on daedalus

2002-04-15 Thread Jeff Trawick
Cliff Woolley <[EMAIL PROTECTED]> writes: > Okay, so this is a totally different problem. Tangentially related at > best. > > Here's the situation: > > 1) create a brigade in pool p (call it r->pool) > 2) create an mmap in the same pool or a subpool > (note: it might have to be a subpoo

proposed fix for funky Apache binbuild "issue"

2002-04-15 Thread Jeff Trawick
For Apache binary distributions, an environment variable (e.g., LD_LIBRARY_PATH) is used at run-time to locate libapr, libaprutil, libexpat, etc. because the path etched into the httpd executable is the path used when creating the binary distribution, not the path used for the actual install. But

RE: cvs commit: apr/include apr_pools.h

2002-04-15 Thread Sander Striker
Whoa! How long has that been there? Sander > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 15 April 2002 16:05 > To: [EMAIL PROTECTED] > Subject: cvs commit: apr/include apr_pools.h > > > stoddard02/04/15 07:05:07 > > Modified:include apr_po

[PATCH] Rename apr_get_groupname

2002-04-15 Thread Thom May
Hi, this is a patch to rename apr_get_groupname to apr_group_name_get Patch for httpd2 is following, svn is not touched. -- Thom May -> [EMAIL PROTECTED] The memory management on PowerPC can be used to frighten small children. -- Linus Torvalds Index: renames_pending ===

Re: UUID logic required in APR?

2002-04-15 Thread Aaron Bannert
> > -1 on moving it, unless we are dumping the Win32 uuid.c source which > > uses the OS to generate uuid's. > > Is there any reason not to use the variant in the unix directory? > This way our UUIDs will be consistent across platforms. -- justin It just depends on how we define "uniqueness" WRT

Re: [Patch] Rename apr_explode_time

2002-04-15 Thread Justin Erenkrantz
On Sun, Apr 14, 2002 at 11:17:56PM +0100, Thom May wrote: > Patch to rename apr_explode_time to apr_time_exp_tz > This does not impact apache2, and an svn patch is on it's way to that > mailing list too. Committed. Thanks! -- justin