compile/link of apr based programs

2002-09-17 Thread Doug MacEachern
i'm seeing bits-n-pieces of what the current proper way of compiling and linking an apr based program is. would be very helpful to see the complete steps given the simple program below. or is it already documented somewhere? i tried the following: CFLAGS=`$APR_CONFIG --cflags --includes`

Re: compile/link of apr based programs

2002-09-17 Thread Doug MacEachern
On Tue, 17 Sep 2002, Justin Erenkrantz wrote: You need to use apu-config. -- justin ah, closer but apu-config --link-ld gives me -L/.../lib -laprutil rather than -laprutil-0 if test $location = installed; then ### avoid using -L if libdir is a standard location like /usr/lib

Re: apr_uuid is not thread safe

2002-06-19 Thread Doug MacEachern
more problems: static int uuid_state_seqnum; static unsigned char uuid_state_node[NODE_LENGTH] = { 0 };

apr_date_parse_rfc segv

2002-05-23 Thread Doug MacEachern
the program below segvs because apr_date_parse_rfc does the following in a number of places: APU_DECLARE(apr_time_t) apr_date_parse_rfc(char *date) ... timstr = date + 10; timstr[6] = '0'; is one expected to apr_pstrdup the input string or just be ok with it being

Re: cvs commit: apr-util/misc apr_rmm.c

2002-03-15 Thread Doug MacEachern
just noticed another problem, rv never gets set here: apr_status_t rv; ... if ((this = apr_rmm_malloc(rmm, reqsize)) 0) { return rv; } thinking it should be APR_EINVAL, but the return type of apr_rmm_realloc is apr_rmm_off_t. then again, both apr_rmm_{calloc,malloc}

Re: moving ap_ht_time to apr_date_ht_time?

2002-01-29 Thread Doug MacEachern
correction: the suggestion was moving ap_ht_time() to apr_date_format_http(). output of which can be parsed by apr_date_parse_http().

Re: Outch - what a tangled web.

2002-01-06 Thread Doug MacEachern
i wouldn't object to special casing to make win32 happy. though i find it odd that things are working ok as-is on my win32 box and on others. is there any info i can give you about my win32 setup that would help? fwiw your script outputs the following on my box: localhost is at 127.0.0.1

disabling dbm stuff

2001-12-10 Thread Doug MacEachern
there needs to be a way to turn off db, gdbm, etc. for example: --enable-dbm-only=sdbm (turn off everything except sdbm) --disable-dbm=gdbm (turn off just gdbm) doesn't matter what the configure arguments are called, but this functionality needs to be in place.

Re: dbm changes broke httpd-2.0

2001-11-29 Thread Doug MacEachern
On Wed, 28 Nov 2001, Aaron Bannert wrote: I'm seeing the same problem, and it is definately because we're not checking if the libraries exist. I was working on this earlier, lemme see if I can come up with a patch. cool. in the meantime for anybody else who is stuck, this bandaid will get

Re: cvs commit: apr-util/buckets apr_buckets_file.c

2001-11-28 Thread Doug MacEachern
On Tue, 27 Nov 2001, Cliff Woolley wrote: +1 on concept, but if you're going to do this, the things need APR_ namespace protection. ok, wasn't sure if those values might already be defined in a system header file. if so, then i'll change to: #ifdef MMAP_THXéRæOLD # define

Re: apr_buckets_file.c:file_read + XTHREAD

2001-11-28 Thread Doug MacEachern
On Tue, 27 Nov 2001, Cliff Woolley wrote: Nope, scratch that, it won't even happen in that case. Duh. The split/copied file buckets point to the _same_ apr_bucket_file struct and therefore the _same_ apr_file_t. Only once will we ever see that apr_file_t as APR_XTHREAD, at which point we

Re: apr_buckets_file.c:file_read + XTHREAD

2001-11-28 Thread Doug MacEachern
the specific case i'm looking at now is mod_ssl. if the filelength is 4Mb, performance really blows chunks. calling apr_file_read (or xread) directly instead of apr_bucket_read() would improve things a great deal.

XtOffsetOf

2001-08-18 Thread Doug MacEachern
conflicts with php: In file included from /home/dougm/ap/prefork/include/apr_buckets.h:61, from /home/dougm/ap/prefork/include/util_filter.h:59, from sapi_apache2.c:33: /home/dougm/ap/prefork/include/apr_general.h:115:19: warning: XtOffsetOf redefined

apr_uri naming

2001-08-01 Thread Doug MacEachern
the UNP_* flags should probably have an APR_URI_ (or APU_URI_?) prefix. whats with APU_URI anyhow, if we have apr_uri_components. doesn't matter to me which, but it should be one or the other, apu or apr? and the in the move, the functions were not properly renamed, eg.

apr_sockaddr_info_get + server startup time

2001-07-23 Thread Doug MacEachern
with a small number of vhosts configured, it takes ages for the server to start. the bottleneck is alloc_listener() - apr_sockaddr_info_get() - getaddrinfo() call with the default 0.0.0.0 address. this patch avoids the lengthy lookup time and the server fires up right away. could this be done

Re: apr_sockaddr_info_get + server startup time

2001-07-23 Thread Doug MacEachern
On 23 Jul 2001, Jeff Trawick wrote: I was thinking that we simply needed to set hints.ai_flags to 0 (I'd have done it already if I were 100% sure). Later, maybe we need to add a special flag to apr_sockaddr_info_get() to have it then turn on AI_CANONNAME, but for now AI_CANONNAME doesn't

apr_strcat optimization(s)

2001-06-19 Thread Doug MacEachern
the current apr_strcat does strlen() twice for each argument, this patch makes it happen just once. it would also be handy to have an apr_pstrcatn (name debatable) that returns the calculated length so the caller can avoid another strlen(), something like: apr_size_t total_len; apr_status_t

Re: apr_strcat optimization(s)

2001-06-19 Thread Doug MacEachern
On 19 Jun 2001, Jeff Trawick wrote: better to memcpy() and then set *cp to '\0' when done... strncpy() is more expensive because agreed. More importantly, I think your patch is broken. Likely I'm confused, but I don't see how the terminating '\0' gets added in your patch. strncpy()

Re: apr_strcat optimization(s)

2001-06-19 Thread Doug MacEachern
On 19 Jun 2001, Jeff Trawick wrote: cp doesn't point to the end of the string to be built yet. If you had *(cp + len) = '\0'; then I'd believe you. oh right, here is the current patch.. --- srclib/apr/strings/apr_strings.c2001/05/10 18:05:18 1.13 +++

Re: Moving stuff from server/util_* into apr-util?

2001-05-17 Thread Doug MacEachern
On Wed, 16 May 2001, Justin Erenkrantz wrote: Hi gang, I keep running into files (server/util_date.c, server/util_uri.c) that can be extremely useful outside of httpd-2.0. What would people think about trying to move some of that code inside of apr-util? i would very much like to see this

Re: Memory Renaming (try 2)

2001-05-11 Thread Doug MacEachern
On Fri, 11 May 2001, Luke Kenneth Casson Leighton wrote: [clearer hierarchy. 4 months ago there was a mad-perl-script hack-against-the-code to turn all names around :) ] that script is still here: http://perl.apache.org/~dougm/apr_rename.pl just nuke everything after the __DATA__ token,

Re: apr_threadkey

2001-04-30 Thread Doug MacEachern
On Sun, 29 Apr 2001 [EMAIL PROTECTED] wrote: On Sun, 29 Apr 2001, Doug MacEachern wrote: wait a sec, i am blind. apr_threadkey_private_{get,set} does what i expected. its apr_threadkey_data_{get,set} that uses apr_pool_userdata_{get,set}. this part of the api should probably

apr_threadkey

2001-04-29 Thread Doug MacEachern
it looks like apr_threadkey_t cannot be used as tls is meant to be. for example: static apr_threadkey_t *thr_key; static void hook_post_config(apr_pool_t *pconf, ...) { apr_threadkey_private_create(thr_key, NULL, pconf); } it is not possible to use thr_key at request time because

Re: apr_threadkey

2001-04-29 Thread Doug MacEachern
wait a sec, i am blind. apr_threadkey_private_{get,set} does what i expected. its apr_threadkey_data_{get,set} that uses apr_pool_userdata_{get,set}. this part of the api should probably be removed.

apr_os_dso_handle_{put,get}

2001-04-25 Thread Doug MacEachern
cool, apr_os_dso_handle_put/apr_dso_unload is working. i wonder if there should be just one version of these 2 functions, since apr_os_dso_handle_t has been introduced, they should be exactly the same for all platforms (functions below from unix/dso.c) maybe in a new file apr/dso/apr_dso.c, that

Re: apr_dso_handle_close ?

2001-04-18 Thread Doug MacEachern
i don't want to push apr_dso_handle_close() anymore, i understand that it is not right for the public apr api. consider my patch recinded. i will submit a patch for apr_dso_make, if i can cvs up my tree (its been hanging all morning). and will patch Perl to make the native close available from

Re: apr_dso_handle_close ?

2001-04-17 Thread Doug MacEachern
On Mon, 16 Apr 2001 [EMAIL PROTECTED] wrote: My biggest problem with passing in a void *, and using it as the dlhandle to close, is that it won't work in error cases on some platforms. OS/2 requires that we save the error message when the error happens, at least that is my understanding.

Re: apr_dso_handle_close ?

2001-04-17 Thread Doug MacEachern
below is a complete patch to implement apr_dso_handle_close() the only cleanup that saved into apr_dso_handle_t was os390: dso-failing_errno = errno; which is pointless since that value is returned by the function and nothing was checking it anyways. as you can see, the patch does not change any

apr_gethostname()

2001-03-16 Thread Doug MacEachern
i just noticed that this function takes an apr_pool_t* argument, but none of the implementations (unix, win32 , os2) use it for anything. any reason not to remove this unused arg?

Re: apr_gethostname()

2001-03-16 Thread Doug MacEachern
On Thu, 15 Mar 2001 [EMAIL PROTECTED] wrote: Yes. All APR functions must have acess to a pool. Imagine a platform that requires we allocate memory for gethostname before we call the system call. If we don't pass the pool, we can't allocate the memory. We are trying to be future proof,

Re: apr_ function prefixes

2001-02-08 Thread Doug MacEachern
On Tue, 6 Feb 2001, Roy T. Fielding wrote: +1 a.s.a.p. ok, i'm planning todo it later this evening.

Re: apr_ function prefixes

2001-02-08 Thread Doug MacEachern
to see the files that will change and the line number/name change: http://perl.apache.org/~dougm/apr_rename.txt feel free to shout if anything looks wrong, i won't commit for a few hours.

Re: apr_ function prefixes

2001-02-08 Thread Doug MacEachern
On Wed, 7 Feb 2001, B. W. Fitzpatrick wrote: +1. Wow that looks great. A toast to consistency! i'll drink to that :) Is there any way you could forward along the conversion script that you used (Or is that the one you sent last week)? This is going to break Subversion a bit, and maybe I

Re: apr_ function prefixes

2001-02-08 Thread Doug MacEachern
On Thu, 8 Feb 2001, Garrett Rooney wrote: on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put and apr_os_thread_put. i assume that's wrong, since i can't for the life of me figure out what pupt would mean ;-) whoops! you're right, i'll fix that and pupt the changes back

Re: cvs commit: apr-util/include apr_hooks.h

2001-02-02 Thread Doug MacEachern
On Fri, 2 Feb 2001, Greg Stein wrote: Are those ap structures from Apache? Conversely, they aren't appearing within APR(UTIL) are they? the list of ap structures is below, ap_LINK_* make up 20 of the 39 reported. ap_bucket_error ap_directive_t ap_filter_func ap_filter_rec_t ap_filter_t

apr_item_t

2001-01-23 Thread Doug MacEachern
i have a little source tree comber for mapping apache/apr types/functions to Perl and noticed this is unused. should it go away now that btable is gone? /** * A transparent type for items stored in binary-content tables, and * possibly elsewhere. */ typedef struct apr_item_t { /** The key

largefile support

2001-01-21 Thread Doug MacEachern
as some of you may know, perl 5.6.0+ enables largefile support by default. in order for mod_perl+apache to cooperate, the lfs flags must either be stripped when mod_perl is built or apache must be built with these flags, e.g. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 however, this is not