Re: shtool invokes head but misses and invokes something else?
At 05:03 PM 02/08/2001, Wilfredo Sanchez wrote: Unknown option: 1 Usage: head [-options] ... -muse method for the request (default is 'HEAD') This looks like a Perl program, from the LWP package (get, head, post). -- Greg Marr [EMAIL PROTECTED] "We thought you were dead." "I was, but I'm better now." - Sheridan, "The Summoning"
Re: shtool invokes head but misses and invokes something else?
> Apparently, shtool is invoking "head -1" which should be fine, because > head *does* accept a -1 argument, but instead some other program with > the above usage is being invoked and I can't figure out why this might > be the case. Anybody recognize that usage output? Certainly looks > Apache-ish, but I can't find it in APR. It is the output from libwww-perl's head script, which should have been installed as lwphead or HEAD to avoid this conflict. shtool should be using an absolute path anyway. Roy
Re: cvs commit: apr configure.in
On Thu, Feb 08, 2001 at 10:12:28PM -, [EMAIL PROTECTED] wrote: > trawick 01/02/08 14:12:28 > > Modified:.configure.in > Log: > look in -lm for modf() > > This gets APR test programs linking on Tru64. It may result in a > double -lm on some platforms, as we autodetect the need for -lm > but also hard-code the need for it in hints.m4. Wouldn't that imply that -lm should be removed from hints.m4? Recall: hints.m4 was a bridge between the old Apache 1.3 knowledge of systems, and our *detection* based system (embodied in autoconf). Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
On Thu, Feb 08, 2001 at 02:44:08PM -0800, [EMAIL PROTECTED] wrote: > > > On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote: > > > > > >> It looks like Greg has taken care of Subversion, but did anyone else see > > >> Doug's commit message go by or did my mailer drop it on the floor? > > > > > > i committed at the top-level and it mailed the diff for everything to > > > [EMAIL PROTECTED] > > > > Urgh. Guess it's time for me to subscribe to a new list. > > > > :) > > I'm trying to figure out how to make CVS send mail to the right > repository, even if the commit is from a higher directory. Tough problem. And you better know your Perl :-) Do you intend to create multiple messages, or just send the same one to (all) mailing lists? Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: shtool invokes head but misses and invokes something else?
On Thu, 8 Feb 2001, Wilfredo Sanchez wrote:
> Anybody recognize that usage output? Certainly looks
> Apache-ish, but I can't find it in APR.
It's a Perl script that's part of LWP:
pantheon: ~>HEAD -1
Unknown option: 1
Usage: HEAD [-options] ...
-muse method for the request (default is 'HEAD')
-fmake request even if HEAD believes method is illegal
-b Use the specified URL as base
-t Set timeout value
-i Set the If-Modified-Since header on the request
-c use this content-type for POST, PUT, CHECKIN
-aUse text mode for content I/O
-p use this as a proxy
-Pdon't load proxy settings from environment
-Hsend this HTTP header (you can specify several)
-uDisplay method and URL before any response
-UDisplay request headers (implies -u)
-sDisplay response status code
-SDisplay response status chain
-eDisplay response headers
-dDo not display content
-oProcess HTML content in various ways
-vShow program version
-hPrint this message
-xExtra debugging output
pantheon: ~>which HEAD
/usr/bin/HEAD
pantheon: ~>head /usr/bin/HEAD
#!/usr/bin/perl -w
eval 'exec /usr/bin/perl -w -S $0 ${1+"$@"}'
if 0; # not running under some shell
# $Id: lwp-request.PL,v 1.39 1999/10/28 12:13:21 gisle Exp $
#
# Simple user agent using LWP library.
=head1 NAME
pantheon: ~>
-Fitz
Re: [PATCH] a somewhat different approach to the iconv() issue
> > 1) The #ifdef APR_ in xlate.c must be a #if > > Why is that? We generally use #ifdef FOO if FOO is sometimes defined > and sometimes not (e.g., APR_ICONV_INBUF_CONST). We generally use #if > FOO if FOO is always defined but sometimes to 1 and sometimes to 0 > (e.g., APR_HAS_XLATE). Sorry, I just misread the code -- it is setting the internal variable to 1 or 0, but only does the define if it is 1. My goof. > > 2) The test is looking at the versions and triggering #error > > > > I don't know why the version test is giving a false-positive, nor > > do I particularly care -- I don't think this can be fixed by assuming > > the version numbers mean anything. The fix I am working on is a > > replacement for AC_TRY_COMPILE, but m4 isn't one of my strong > > points. > > I don't follow your comment about "assuming the version numbers mean > anything". Maybe if I saw the version numbers in glibc 2.2's > it would be easy to follow what you are saying. > > If you can get -Werror working for gcc, obviously we don't need the > glibc version check since we can expect to use gcc on a platform which > uses glibc 99.99% of the time, but I can't help but be curious about > why it generated the #error on RH 7.0 which has glibc 2.2 (and I guess > __GLIBC_MINOR__ == 2). Oh, that's probably the problem -- it is __GLIBC_MINOR in the macro. Anyway, I've coded up the tester as APR_TRY_GCC_WARNING and will commit. Please give it a try on your platform and fix where needed. I think it will fail-safe, but I'm still too sane to be able to follow all of the possible m4 paths. No worries about the license -- the m4 include files have effectively the same license as the autoconf library, and since they don't get added to the object file they cannot cause our code to be considered "derived from GPL code". Roy
Re: cvs commit: apr configure.in
Greg Stein <[EMAIL PROTECTED]> writes: > On Thu, Feb 08, 2001 at 10:12:28PM -, [EMAIL PROTECTED] wrote: > > trawick 01/02/08 14:12:28 > > > > Modified:.configure.in > > Log: > > look in -lm for modf() > > > > This gets APR test programs linking on Tru64. It may result in a > > double -lm on some platforms, as we autodetect the need for -lm > > but also hard-code the need for it in hints.m4. > > Wouldn't that imply that -lm should be removed from hints.m4? I expect that over the next few days I'll remove it for the relatively few platforms I have access to as I get a chance to verify. Alternatively, we can just remove it across the board and pick up the pieces when somebody with one of the obscure systems gets an unresolved reference and we realize that we need to look for a different function in -lm. Are you in favor of the latter approach? Thanks, -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: apr_ function prefixes
Jeff Trawick <[EMAIL PROTECTED]> writes: > Garrett Rooney <[EMAIL PROTECTED]> writes: > > > 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 ;-) > > good for you > > if sleeping child cooperates I'll fix it up Real Soon Now... well, all I got was cvs not-up-to-date messages :) mailing list delays are no fun... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: shtool invokes head but misses and invokes something else?
On Thursday, February 8, 2001, at 04:14 PM, Roy T. Fielding wrote: It is the output from libwww-perl's head script, which should have been installed as lwphead or HEAD to avoid this conflict. Aw, hell. [joliet-jake:~] wsanchez% file /usr/bin/head /usr/bin/head: perl commands text What kinda stupid distribution stomps on system software in the default install like that? Sheesh. Looks I need to undo some damage. Thanks. -Fred
Re: shtool invokes head but misses and invokes something else?
Oh, I get it. LPW tries to install /usr/bin/HEAD and stomps /usr/bin/head because it's HFS+. Eit. -Fred Wilfredo Sánchez - [EMAIL PROTECTED] Apache Software Foundation
Re: cvs commit: apr configure.in
On Thu, Feb 08, 2001 at 07:56:14PM -0500, Jeff Trawick wrote: > Greg Stein <[EMAIL PROTECTED]> writes: > > > On Thu, Feb 08, 2001 at 10:12:28PM -, [EMAIL PROTECTED] wrote: > > > trawick 01/02/08 14:12:28 > > > > > > Modified:.configure.in > > > Log: > > > look in -lm for modf() > > > > > > This gets APR test programs linking on Tru64. It may result in a > > > double -lm on some platforms, as we autodetect the need for -lm > > > but also hard-code the need for it in hints.m4. > > > > Wouldn't that imply that -lm should be removed from hints.m4? > > I expect that over the next few days I'll remove it for the relatively > few platforms I have access to as I get a chance to verify. > > Alternatively, we can just remove it across the board and pick up the > pieces when somebody with one of the obscure systems gets an > unresolved reference and we realize that we need to look for a > different function in -lm. > > Are you in favor of the latter approach? The latter... definitely :-) It is a bit nicer to believe we have the right solution and then apply known fixes, then to continue to carry around baggage which we never know is still needed or not. In this particular case, the "failure mode" is an easy diagnosis and fix. Ideally, hints could go away, but realistically I doubt that :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr-util/include apr_buckets.h
> rbb 01/02/08 22:19:44 > > Modified:buckets apr_brigade.c >include apr_buckets.h > Log: > Allow brigades to buffer data natively with apr_brigade_write, > apr_brigade_puts, etc. This uses a heap bucket to store the data at the > end of the brigade. If the bucket overflows, then we call the flush > function that is passed in to flush the brigade to the correct location. > Submitted by: Ryan Bloom and Greg Stein > WooHoo!!! Bill
Re: cvs commit: apr CHANGES apr_common.m4
[EMAIL PROTECTED] writes: > fielding01/02/08 16:56:05 > > Modified:.CHANGES apr_common.m4 > Log: > Add APR_TRY_GCC_WARNING macro to dynamically test the iconv prototype > if gcc is being used. This turned out a little different than I imagined :) A key characteristic we need is to make sure that our assumption about const-ness compiles at all on the platform, whether or not gcc is being used. It is my understanding that certain platforms besides glibc-2.2+gcc-recent will fail the compile if the const-ness is wrong. IRIX was an example given on the mailing list. An additional characteristic which is extremely nice is to add -Werror to the CFLAGS if the compiler is gcc. That verifies an additional level of correctness without needing the apr_iconv_inbuf_const hint.
Re: cvs commit: apr CHANGES apr_common.m4
> A key characteristic we need is to make sure that our assumption about > const-ness compiles at all on the platform, whether or not gcc is > being used. It is my understanding that certain platforms besides > glibc-2.2+gcc-recent will fail the compile if the const-ness is > wrong. IRIX was an example given on the mailing list. I remembered that as well while in the shower this morning. I'll fix it. Roy
libmm
OK, make on Darwin finishes without errors. I get these libraries: [joliet-jake:~/Developer/Apache/apr] wsanchez% find . -name \*.dylib -o -name \*.a ./.libs/libapr.a ./.libs/libapr.dylib ./shmem/unix/mm/.libs/libmm.a Do I want to work on getting libmm to build dynamically, or is it expected to be static? (Do clients say "-lapr" or "-lapr -lmm"? I'm hoping it's the former, in which case I'd expect libapr to link against libmm, which I'm not seeing...) -Fred
Re: libmm
>OK, make on Darwin finishes without errors. I get these libraries: > > [joliet-jake:~/Developer/Apache/apr] wsanchez% find . -name \*.dylib -o > -name \*.a > ./.libs/libapr.a > ./.libs/libapr.dylib > ./shmem/unix/mm/.libs/libmm.a > >Do I want to work on getting libmm to build dynamically, or is it > expected to be static? > >(Do clients say "-lapr" or "-lapr -lmm"? I'm hoping it's the former, > in which case I'd expect libapr to link against libmm, which I'm not > seeing...) The problem is Libtool (like usual). Libtool treats everything as a shared library, so in APRVARS, we set LIBTOOL_LIBS to the libmm.la file, and Apache uses LIBTOOL_LIBS to find and link against other libtool libraries. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: libmm
On Fri, Feb 09, 2001 at 11:54:22AM -0800, Wilfredo Sanchez wrote: >OK, make on Darwin finishes without errors. I get these libraries: > > [joliet-jake:~/Developer/Apache/apr] wsanchez% find . -name \*.dylib -o > -name \*.a > ./.libs/libapr.a > ./.libs/libapr.dylib > ./shmem/unix/mm/.libs/libmm.a > >Do I want to work on getting libmm to build dynamically, or is it > expected to be static? > >(Do clients say "-lapr" or "-lapr -lmm"? I'm hoping it's the former, > in which case I'd expect libapr to link against libmm, which I'm not > seeing...) Hmm. Normally, Apache tells APR and APRUTIL to build statically, by passing --disable-shared (to libtool). Not sure why you have a .dylib for APR unless you separately configured it without that switch. APR should be passing the same flag(s) to the MM configuration, which would result in it seeing --disable-shared also. I'm guessing that you're seeing some kind of skew in there. Regarding linking, clients are expected to use apr/libapr.la plus anything they find in LIBTOOL_LIBS in APRVARS (and yes: there is a status item to namespace protect the stuff in APRVARS). If client apps are not libtool-aware, then it is best for them to use an installed copy of APR. The .a and/or .so will be directly available at the install point. [ although we don't have "install" working for APR(UTIL) at this point ] Cheers, -g -- Greg Stein, http://www.lyra.org/
