Re: cvs commit: apr CHANGES configure.in
On 28 May 2002 [EMAIL PROTECTED] wrote: jwoolley02/05/28 16:15:10 Modified:.CHANGES configure.in Log: Added --with-devrandom=[DEV] configure flag which allows a particular /dev/random-compatible device to be specified, overriding the default search path (/dev/random then /dev/arandom then /dev/urandom). Also, if --with-egd=path is specified, it now implies --without-devrandom. Okay, Ben, I believe this patch implements what you've said you prefer, and it makes a lot of sense to me as well. Here's what we have now: 1) If --with-egd=path is specified, --without-devrandom is assumed and the EGD socket is used as the source of entropy. 2) Otherwise, if --with-devrandom=DEV is specified with a particular device, that device is used as the source of entropy. 3) Otherwise, if --with-devrandom (with no =DEV) is specified or --with-devrandom is not specified at all, we search /dev/random /dev/arandom /dev/urandom in that order. 4) If the search in #3 fails, we try looking for the truerand library. 5) If none of the above is usable, we have no source of entropy. Does that sound right? --Cliff
Re: cvs commit: apr CHANGES configure.in
Oops, I missed one thing: On Tue, 28 May 2002, Cliff Woolley wrote: 1) If --with-egd=path is specified, --without-devrandom is assumed and the EGD socket is used as the source of entropy. 2) Otherwise, if --with-devrandom=DEV is specified with a particular device, that device is used as the source of entropy. 3) Otherwise, if --with-devrandom (with no =DEV) is specified or --with-devrandom is not specified at all, we search /dev/random /dev/arandom /dev/urandom in that order. 4) If the search in #3 fails, ...or if --without-devrandom was specified we try looking for the truerand library. 5) If none of the above is usable, we have no source of entropy.
Re: cvs commit: apr CHANGES configure.in
Cliff Woolley wrote: On 28 May 2002 [EMAIL PROTECTED] wrote: jwoolley02/05/28 16:15:10 Modified:.CHANGES configure.in Log: Added --with-devrandom=[DEV] configure flag which allows a particular /dev/random-compatible device to be specified, overriding the default search path (/dev/random then /dev/arandom then /dev/urandom). Also, if --with-egd=path is specified, it now implies --without-devrandom. Okay, Ben, I believe this patch implements what you've said you prefer, and it makes a lot of sense to me as well. Here's what we have now: 1) If --with-egd=path is specified, --without-devrandom is assumed and the EGD socket is used as the source of entropy. 2) Otherwise, if --with-devrandom=DEV is specified with a particular device, that device is used as the source of entropy. 3) Otherwise, if --with-devrandom (with no =DEV) is specified or --with-devrandom is not specified at all, we search /dev/random /dev/arandom /dev/urandom in that order. 4) If the search in #3 fails, we try looking for the truerand library. 5) If none of the above is usable, we have no source of entropy. Does that sound right? I still say it needs to be configurable at runtime as well. Apart from that, yes. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
Re: cvs commit: apr CHANGES configure.in
On Monday 13 August 2001 22:54, Justin Erenkrantz wrote: On Tue, Aug 14, 2001 at 05:15:00AM -, [EMAIL PROTECTED] wrote: rbb 01/08/13 22:15:00 Modified:.CHANGES configure.in Log: Fix the new shared memory configure script. The APR_DECIDE macros go in order, so the last set of dependancies that are met are the ones used. That means that when using those macros, options should be listed with the least desirable option first, and the most desirable last. The new shared memory routines did the opposite, so we chose the wrong shared memory option on Linux. CS: Obtained from: Eh, what? Don't we want to avoid MMAP on a temporary file? This seems contrary to how I understand things. Now, we have to have enough disk space to back the shared memory. Ack. The ordering was as I intended and is similar to the ordering in MM. MAP_ANON should be our preference on Linux. There are some reports that older versions of Linux don't support MAP_ANON properly. But, I haven't run across that yet. -- justin Well, looking at MM, it decides to use IPCSHM on my linux box. I was unable to make my machine work when using MAP_ANON. I also looked at what we did for Apache-1.3. We used SHMGET for Linux on 1.3. This makes me think we should be using SHMGET on linux. I just did what I needed to, to get Linux up and running again. If you can make MAP_ANON work, great. Otherwise, for right now, we have a working server. :-) Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: apr CHANGES configure.in
On Mon, Aug 13, 2001 at 11:03:50PM -0700, Ryan Bloom wrote: Well, looking at MM, it decides to use IPCSHM on my linux box. I was unable to make my machine work when using MAP_ANON. I also looked at what we did for Apache-1.3. We used SHMGET for Linux on 1.3. This makes me think we should be using SHMGET on linux. I just did what I needed to, to get Linux up and running again. If you can make MAP_ANON work, great. Otherwise, for right now, we have a working server. :-) Ah, Mandrake 7.2, right? Linux 2.2-based... Aha. I wonder if they fixed MAP_ANON in Linux 2.4. MAP_ANON worked fine with a 2.4 series kernel. So, we could add an override for 2.4 (what about 2.3?) to not use MAP_ANON. I wonder why SHMGET wasn't working - it worked fine on Solaris (so the code should supposedly work on Linux). Wouldn't /dev/zero be a better choice than a temporary file? I think even 2.2 has support for that. I'll try testing with a Linux 2.2 machine (hopefully soon). If I can figure out the right way to avoid using MAP_ANON in 2.2 (or other brokenness), I'll revert to the previous order with appropriate safeguards. -- justin
Re: cvs commit: apr CHANGES configure.in
On Monday 13 August 2001 23:17, Justin Erenkrantz wrote: On Mon, Aug 13, 2001 at 11:03:50PM -0700, Ryan Bloom wrote: Well, looking at MM, it decides to use IPCSHM on my linux box. I was unable to make my machine work when using MAP_ANON. I also looked at what we did for Apache-1.3. We used SHMGET for Linux on 1.3. This makes me think we should be using SHMGET on linux. I just did what I needed to, to get Linux up and running again. If you can make MAP_ANON work, great. Otherwise, for right now, we have a working server. :-) Ah, Mandrake 7.2, right? Linux 2.2-based... Aha. I wonder if they fixed MAP_ANON in Linux 2.4. MAP_ANON worked fine with a 2.4 series kernel. So, we could add an override for 2.4 (what about 2.3?) to not use MAP_ANON. I wonder why SHMGET wasn't working - it worked fine on Solaris (so the code should supposedly work on Linux). Wouldn't /dev/zero be a better choice than a temporary file? I think even 2.2 has support for that. I'll try testing with a Linux 2.2 machine (hopefully soon). If I can figure out the right way to avoid using MAP_ANON in 2.2 (or other brokenness), I'll revert to the previous order with appropriate safeguards. -- justin Okay, sounds good. As for the options other than MMAP_TMP, I didn't really do a lot of testing. I removed as many warnings as I could, and just tried to figure out what you were trying to do with the configure script. Obviously, I got it completely wrong. :-) Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: apr CHANGES configure.in
Boolean switches should use AC_ARG_ENABLE(). AC_ARG_WITH is to allow you to specify configure with this package. The code below should fall out simply as: AC_ARG_ENABLE(sendfile, [ --enable-sendfile Enable or disable sendfile support] [ if test $enable_sendfile = yes; then sendfile=1 else sendfile=0 fi ]) No switch leaves sendfile unset (e.g. default to the platform availability). --enable-sendfile sets it to 1, and --disable-sendfile sets it to 0. Users expect AC_ARG_ENABLE type switches for these things. (--with-debug and --with-maintainer-mode need to switch, too, for that matter) Cheers, -g On Tue, Mar 06, 2001 at 12:10:42PM -0800, [EMAIL PROTECTED] wrote: On Tue, 6 Mar 2001, Roy T. Fielding wrote: On Tue, Mar 06, 2001 at 04:54:49AM -, [EMAIL PROTECTED] wrote: +++ configure.in2001/03/06 04:54:49 1.256 @@ -350,6 +350,13 @@ dnl threaded poll() and we don't want to use sendfile on early FreeBSD dnl systems if we are also using threads. +AC_ARG_WITH(sendfile, [ --with-sendfile Force sendfile to be on or off], + [ if test $withval = yes; then +sendfile=1 +else +sendfile=0 +fi ] ) + This seems to say that --with-sendfile means --without-sendfile. I think that --with options should always default to yes if no =value is given. Otherwise, the option should be --disable-sendfile. The way that autoconf works, by using AC_ARG_WITH, we get multiple options: --with-sendfile=yes --with-sendfile --with-sendfile=no --without-sendfile The first two are the same, as are the last two. The logic in that file makes --with-sendfile force sendfile to be on, and --without-sendfile to force it to be off. Ryan ___ Ryan Bloom[EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 --- -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr CHANGES configure.in
Sure it can support multiple flags. If I do: ./configure --with-optim=-O2 -O2 It will work... Hmmm... it wasn't working for me -- something was stripping the double-quotes off the comand-line arguments, such that the command-line could not be reconstructed faithfully, and thus config.nice was getting invalid arguments. I tried to fix that in the macro that created config.nice, but the quotes were being stripped earlier somewhere (I assume the option reader). This may have been a problem in the httpd configure only, but consensus on the list was that we should be using OPTIM anyway. Roy
Re: cvs commit: apr CHANGES configure.in
On 28 Jan 2001 [EMAIL PROTECTED] wrote: | + *) Replace configure --with-optim option by using the environment | + variable OPTIM instead. This is needed because configure options | + do not support multiple flags separated by spaces. [Roy Fielding] | + Sure it can support multiple flags. If I do: ./configure --with-optim=-O2 -O2 It will work... make[4]: Entering directory `/local/src/apache-dev/httpd-2.0/srclib/apr/lib' /bin/sh /local/src/apache-dev/httpd-2.0/srclib/apr/libtool --mode=compile --silent gcc -DSOLARIS2=8 -pthreads -pthreads -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -O2 -O2 -I../include -I../include/arch/unix -I../include/arch/unix -c apr_pools.c touch apr_pools.lo /dale
