Re: prefork mpm in linux: ap_process_connection isn't called on connection
On Mar 31, 2006, at 6:42 AM, Jeff Trawick wrote: On 3/28/06, Rian A Hunter <[EMAIL PROTECTED]> wrote: On the httpd trunk in prefork.c ap_process_connection isn't called until there is data on the new connection (instead of just when a client connects). Is there a kernel accept filter enabled? No, it is a default clean install. Are you suggesting that for me to get the behavior I want that there should be one enabled? Rian
Re: [PATCH] htdbm: warn crypt-enabled users that plaintext format won't work
Taking things one step further, sha1 is far preferred for cryptographic purposes these days than md5. Suppose its time to switch? Bill Jeff Trawick wrote: Index: support/htdbm.c === --- support/htdbm.c (revision 390811) +++ support/htdbm.c (working copy) @@ -308,6 +308,10 @@ case ALG_PLAIN: /* XXX this len limitation is not in sync with any HTTPd len. */ apr_cpystrn(cpw,htdbm->userpass,sizeof(cpw)); +#if APR_HAVE_CRYPT_H +fprintf(stderr, "Warning: Plain text passwords aren't supported by the " +"server on this platform!\n"); +#endif break; #if APR_HAVE_CRYPT_H case ALG_CRYPT: FWIW, when you choose crypt() you see "CRYPT is now deprecated, use MD5 instead!" As I understand the plaintext password issue: In the database file, there are special denotations for md5 and sha1 password hashes, and if there is no denotation then the server expects (defaults to) crypt() format. But on Windows no crypt() function is available, so no denotation means plaintext format there. 1) design issue: file format doesn't have a delimeter for plain text, so a server on Unix has no way to support plaintext passwords 2) usability issue: htdbm doesn't warn users on platforms with crypt() that it is fruitless to specify plaintext format for password
[PATCH] htdbm: warn crypt-enabled users that plaintext format won't work
Index: support/htdbm.c === --- support/htdbm.c (revision 390811) +++ support/htdbm.c (working copy) @@ -308,6 +308,10 @@ case ALG_PLAIN: /* XXX this len limitation is not in sync with any HTTPd len. */ apr_cpystrn(cpw,htdbm->userpass,sizeof(cpw)); +#if APR_HAVE_CRYPT_H +fprintf(stderr, "Warning: Plain text passwords aren't supported by the " +"server on this platform!\n"); +#endif break; #if APR_HAVE_CRYPT_H case ALG_CRYPT: FWIW, when you choose crypt() you see "CRYPT is now deprecated, use MD5 instead!" As I understand the plaintext password issue: In the database file, there are special denotations for md5 and sha1 password hashes, and if there is no denotation then the server expects (defaults to) crypt() format. But on Windows no crypt() function is available, so no denotation means plaintext format there. 1) design issue: file format doesn't have a delimeter for plain text, so a server on Unix has no way to support plaintext passwords 2) usability issue: htdbm doesn't warn users on platforms with crypt() that it is fruitless to specify plaintext format for password
Re: [VOTE] Release 2.2.1 as GA
Jess Holle wrote: So does that mean if one grabs the 2.2.1 tar ball one will not be able to build on Windows? Correct, but the 2.2.2 tarball will build on windows (with a bumped aprutil). That's why I think the concensus, between borked Win32/Netware and a missing proxy patch, is to reroll and get the 2.2.2 out immediately this week. Oh, my personal vote to the RM's tally is -1 (moving rapidly to 2.2.2). If so, that's not a very compelling tarball for those needing to support Windows. If 2.2.1 is being labeled as non-GA already then that's quite appropriate, move on to 2.2.2 as soon as possible. 2.2.1 shouldn't be labeled as GA if it does not build on Windows "as is", though. 2.2.1 is labeled nothing right now, that's why the thread is [VOTE].
Re: apu_version mess
>>> On 4/3/2006 at 11:38:28 am, in message <[EMAIL PROTECTED]>, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > Paul Querna wrote: >> To resolve the problems we have with calling apu_version from httpd, we >> have three main options: >> >> [ ] Remove the new code that outputted the versions. >> [ ] Make the code only present on systems that didn't have a broken build. >> [X] Wait for APR-Util 1.2.7 to be released. > >... as a bugfix (configuration) release only, and quickly? yes. > >> Votes/Thoughts? >> >> All of the options pretty much mean scraping the 2.2.1 release, and >> moving on to 2.2.2. > > Previous to 1.2.7 Win32 and Netware were borked. > > FYI I'm doing a fast delta on win32/unix (Brad, could you shoot me th My vote would be first "Wait for APR-Util 1.2.7 to be released" if this can happen quickly. Even if the only difference between 1.2.6 and 1.2.7 is the apu_version_string() patch for Win32/NetWare. Otherwise I would go with "Remove the new code that outputted the versions" Brad
Re: [VOTE] Release 2.2.1 as GA
So does that mean if one grabs the 2.2.1 tar ball one will not be able to build on Windows? If so, that's not a very compelling tarball for those needing to support Windows. If 2.2.1 is being labeled as non-GA already then that's quite appropriate, move on to 2.2.2 as soon as possible. 2.2.1 shouldn't be labeled as GA if it does not build on Windows "as is", though. -- Jess Holle William A. Rowe, Jr. wrote: On 4/1/06, Steffen <[EMAIL PROTECTED]> wrote: No go on win32: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings .\Release/httpd.exe : fatal error LNK1120 This is fixed on APR 0.9 / 1.2 branches and 1.3 trunk. Brad's fixed this on 1.2 branch and 1.3 trunk - and I have a pending request to him to ensure it's fixed on 0.9 branch as well. My thought is reroll aprutil, which i'll do tonight. The problem isn't with httpd; the problem's with the maintenance on two platforms, and that's what the release notes/CHANGES will say. Bill
Re: [VOTE] Release 2.2.1 as GA
On 4/1/06, Steffen <[EMAIL PROTECTED]> wrote: No go on win32: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings .\Release/httpd.exe : fatal error LNK1120 This is fixed on APR 0.9 / 1.2 branches and 1.3 trunk. Brad's fixed this on 1.2 branch and 1.3 trunk - and I have a pending request to him to ensure it's fixed on 0.9 branch as well. My thought is reroll aprutil, which i'll do tonight. The problem isn't with httpd; the problem's with the maintenance on two platforms, and that's what the release notes/CHANGES will say. Bill
Re: apu_version mess
Paul Querna wrote: To resolve the problems we have with calling apu_version from httpd, we have three main options: [ ] Remove the new code that outputted the versions. [ ] Make the code only present on systems that didn't have a broken build. [X] Wait for APR-Util 1.2.7 to be released. ... as a bugfix (configuration) release only, and quickly? yes. Votes/Thoughts? All of the options pretty much mean scraping the 2.2.1 release, and moving on to 2.2.2. Previous to 1.2.7 Win32 and Netware were borked. FYI I'm doing a fast delta on win32/unix (Brad, could you shoot me the
AW: apu_version mess
> -Ursprüngliche Nachricht- > Von: Paul Querna > > To resolve the problems we have with calling apu_version from > httpd, we > have three main options: > > [ ] Remove the new code that outputted the versions. > [X] Make the code only present on systems that didn't have a > broken build. > [ ] Wait for APR-Util 1.2.7 to be released. > > Votes/Thoughts? > > All of the options pretty much mean scraping the 2.2.1 release, and > moving on to 2.2.2. > I think that this is wise anyway because I forgot to backport r379237. Meanwhile r379237 has been backported. Without this patch SSL to proxy backends do not work and nearly all ssl proxy tests from the test framework fail. Version numbers are cheap :-). Regards Rüdiger
apu_version mess
To resolve the problems we have with calling apu_version from httpd, we have three main options: [ ] Remove the new code that outputted the versions. [ ] Make the code only present on systems that didn't have a broken build. [ ] Wait for APR-Util 1.2.7 to be released. Votes/Thoughts? All of the options pretty much mean scraping the 2.2.1 release, and moving on to 2.2.2. Thanks, Paul
Re: svn commit: r391080 - in /httpd/mod_smtpd/trunk/src: Makefile.am smtp_bouncer.c smtp_protocol.c smtp_util.c
On 4/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > --- httpd/mod_smtpd/trunk/src/smtp_util.c (original) > +++ httpd/mod_smtpd/trunk/src/smtp_util.c Mon Apr 3 09:40:17 2006 > @@ -76,15 +76,17 @@ > smtpd_run_on_reset_envelope(scr); > smtpd_clear_envelope_rec(scr); > } > - > +#if 0 > #include > #include > #include > +#endif > > SMTPD_DECLARE_NONSTD(apr_status_t) > smtpd_get_mailex(apr_pool_t *pool, /* out */ char **resolved_host, > char *original_host) > { > +#if 0 > /* res_search hack, too dependent */ > unsigned char buf[NS_PACKETSZ]; > ns_msg handle; > @@ -130,6 +132,8 @@ > ns_rr_rdata(rr) + 2, > *resolved_host, > MAXDNAME); > +#endif > +*resolved_host = apr_pstrdup(pool, original_host); > > return APR_SUCCESS; > } If you must #if 0 out code like this, at least leave some indication of why it's been done. Ideally though, I'd suggest just removing it, you can always get it back from the subversion repository if you need it again later. -garrett
RFC: Protecting mod_ssl key with TPM
Here is a patch that adds a feature to allow the mod_ssl key to be bound to a platform TPM (Trusted Platform Module described in specifications by the Trusted Computing Group). This feature is desirable to protect the key from being stolen by an attacker and used on another machine to spoof the secure site. The feature works by encrypting the mod_ssl key with an AES key which is then bound to a TPM and thus usable only on that platform. The tpm_unseal library and tpm_sealdata command for binding the key to the TPM can be found at www.sourceforge.net/projects/trousers in the tpm-tools package. What do others think of this idea? Suggestions on the patch? Thanks, Kylie Hall --- Index: modules/ssl/ssl_util_ssl.c === --- modules/ssl/ssl_util_ssl.c (revision 384633) +++ modules/ssl/ssl_util_ssl.c (working copy) @@ -1,6 +1,8 @@ /* Copyright 2001-2005 The Apache Software Foundation or its licensors, as * applicable. * + * TPMUNSEAL Portions Copyright (C) 2006 IBM Corporation + * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at @@ -25,6 +27,9 @@ */ #include "ssl_private.h" +#ifdef HAVE_TPMUNSEAL +#include +#endif /* _ ** @@ -127,35 +132,49 @@ EVP_PKEY *SSL_read_PrivateKey(char* filename, EVP_PKEY **key, modssl_read_bio_cb_fn *cb, void *s) { -EVP_PKEY *rc; -BIO *bioS; -BIO *bioF; +EVP_PKEY *rc = NULL; +BIO *bioS = NULL; +BIO *bioF = NULL; +#ifdef HAVE_TPMUNSEAL +unsigned char *data = NULL; +int data_len; +int tpmRc = tpmUnsealFile(filename, &data, &data_len); + +if (tpmRc != 0) { +ap_log_error(APLOG_MARK, + ((tpmRc == TPMSEAL_FILE_ERROR && tpm_errno == ENOTSSHDR) + ? APLOG_DEBUG : APLOG_ERR), 0, s, "%s", + tpmUnsealStrerror(tpmRc)); +} +else { +if ((bioS = BIO_new_mem_buf(data, data_len)) == NULL) +return NULL; +BIO_set_close(bioS, BIO_NOCLOSE); +} +#endif + +if (bioS == NULL && (bioS = BIO_new_file(filename, "r")) == NULL) +return NULL; + /* 1. try PEM (= DER+Base64+headers) */ -if ((bioS=BIO_new_file(filename, "r")) == NULL) -return NULL; rc = modssl_PEM_read_bio_PrivateKey(bioS, key, cb, s); -BIO_free(bioS); +BIO_reset(bioS); if (rc == NULL) { /* 2. try DER+Base64 */ -if ((bioS = BIO_new_file(filename, "r")) == NULL) -return NULL; +if ((bioF = BIO_new(BIO_f_base64())) == NULL) +goto out; -if ((bioF = BIO_new(BIO_f_base64())) == NULL) { -BIO_free(bioS); -return NULL; -} -bioS = BIO_push(bioF, bioS); -rc = d2i_PrivateKey_bio(bioS, NULL); -BIO_free_all(bioS); +BIO_push(bioF, bioS); +rc = d2i_PrivateKey_bio(bioF, NULL); +BIO_pop(bioF); +BIO_free(bioF); +BIO_reset(bioS); if (rc == NULL) { /* 3. try plain DER */ -if ((bioS = BIO_new_file(filename, "r")) == NULL) -return NULL; rc = d2i_PrivateKey_bio(bioS, NULL); -BIO_free(bioS); } } if (rc != NULL && key != NULL) { @@ -163,6 +182,13 @@ EVP_PKEY_free(*key); *key = rc; } + + out: +#ifdef HAVE_TPMUNSEAL +if (data) +tpmUnsealShred(data, data_len); +#endif +BIO_free(bioS); return rc; } Index: modules/ssl/config.m4 === --- modules/ssl/config.m4 (revision 384633) +++ modules/ssl/config.m4 (working copy) @@ -12,6 +12,26 @@ dnl See the License for the specific language governing permissions and dnl limitations under the License. +AC_DEFUN([CHECK_TPMUNSEAL], [ + AC_MSG_CHECKING(for tpm-tools unseal library) +save_libs=$LIBS +LIBS="$LIBS -ltpm_unseal" +AC_TRY_LINK( + [#include ], + [tpmUnsealStrerror(0);], + [], + [tmp_no_message="failed to link with tpm_unseal library" + ap_ssltk_ts="no"]) +LIBS=$save_libs +AC_MSG_RESULT($ap_ssltk_ts) +if test "x$ap_ssltk_ts" = "xno"; then + AC_MSG_WARN(tpm_unseal support failed: $tmp_nomessage) +else + APR_ADDTO(MOD_SSL_LDADD,[-ltpm_unseal]) + AC_DEFINE(HAVE_TPMUNSEAL, 1, [Define if tpm_unseal support is enabled]) +fi +]) + AC_DEFUN([CHECK_DISTCACHE], [ AC_MSG_CHECKING(whether Distcache is required) ap_ssltk_dc="no" @@ -117,6 +137,7 @@ APACHE_CHECK_SSL_TOOLKIT APR_SETVAR(MOD_SSL_LDADD, [\$(SSL_LIBS)]) CHECK_DISTCACHE +CHECK_TPMUNSEAL if test "x$enable_ssl" = "xshared"; then # The only symbol which needs to be exported is the module # structure, so ask libtool to hide
Re: [VOTE] Release 2.2.1 as GA
>>> On 4/3/2006 at 8:54:29 am, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: On 4/1/2006 at 12:28 pm, in message > <[EMAIL PROTECTED]>, Paul > Querna <[EMAIL PROTECTED]> wrote: >> 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: >> http://httpd.apache.org/dev/dist/ >> >> Please Test and Vote on releasing 2.2.1 as GA. >> >> MD5s: >> f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 >> 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz >> >> Thanks, >> >> Pau > > -1 NetWare > > Generating Release.o\Apache2_link.opt > Linking Release.o/Apache2.nlm > ### mwldnlm Linker Error: > # Undefined symbol: apu_version_string in > # main.o > > Errors caused tool to abort. > gmake: *** [Release.o/Apache2.nlm] Error 1 > > Seems we have the same missing apu_version_string problem > > Brad SVN rev. 391070 resolves the issue for NetWare. Brad
Re: When did this break?
On Mon, Apr 03, 2006 at 08:53:24AM +0100, Joe Orton wrote: > What's really needed here is a "--with-included-apr"-type flag which > forces use of the bundled sources over installed versions, rather than > trying to overload --with-apr to do that. e.g. this, slightly hacky but does it solve the problem you were having? Index: configure.in === --- configure.in(revision 388210) +++ configure.in(working copy) @@ -61,8 +61,16 @@ echo $ac_n "${nl}Configuring Apache Portable Runtime library ...${nl}" -APR_FIND_APR("$srcdir/srclib/apr", "./srclib/apr", 1, 1) +AC_ARG_WITH(included-apr, +APACHE_HELP_STRING(--with-included-apr,Use bundled copies of APR/APR-Util)) +if test "x$with_included_apr" = "xyes"; then + apr_found=reconfig + apr_config="$srcdir/srclib/apr/apr-1-config" +else + APR_FIND_APR("$srcdir/srclib/apr", "./srclib/apr", 1, 1) +fi + if test "$apr_found" = "no"; then AC_MSG_ERROR([APR not found. Please read the documentation.]) fi @@ -89,7 +97,12 @@ echo $ac_n "${nl}Configuring Apache Portable Runtime Utility library...${nl}" -APR_FIND_APU("$srcdir/srclib/apr-util", "./srclib/apr-util", 1, 1) +if test "x$with_included_apr" = "xyes"; then + apu_found=reconfig + apu_config="${srcdir}/srclib/apr-util/apu-1-config" +else + APR_FIND_APU("$srcdir/srclib/apr-util", "./srclib/apr-util", 1, 1) +fi if test "$apu_found" = "no"; then AC_MSG_ERROR([APR-util not found. Please read the documentation.])
Re: [VOTE] Release 2.2.1 as GA
>>> On 4/1/2006 at 12:28 pm, in message <[EMAIL PROTECTED]>, Paul Querna <[EMAIL PROTECTED]> wrote: > 2.2.1, embedding APR 1.2.6 and APR-Util 1.2.6, is available from: > http://httpd.apache.org/dev/dist/ > > Please Test and Vote on releasing 2.2.1 as GA. > > MD5s: > f330230636926d08872d84343b08fa16 httpd-2.2.1.tar.bz2 > 63e7f3e24adda0888a48a247b4eb5613 httpd-2.2.1.tar.gz > > Thanks, > > Pau -1 NetWare Generating Release.o\Apache2_link.opt Linking Release.o/Apache2.nlm ### mwldnlm Linker Error: # Undefined symbol: apu_version_string in # main.o Errors caused tool to abort. gmake: *** [Release.o/Apache2.nlm] Error 1 Seems we have the same missing apu_version_string problem Brad
AW: mod_http_proxy bug?
> -Ursprüngliche Nachricht- > Von: Brian Akins > > It looks like I'm getting some wierdness with http_proxy. it is not > "returning" any error, but is giving back a 0 length bucket from > apr_bucket_read when it should have some length. This description requires some clarification IMO. Is this 0 length bucket really a data bucket? Is it the last bucket that comes thru your filter or do you see non zero length buckets afterwards for this request? > > is there yet another way to check in a filter (ie, mod_cache > stuff) if > proxy had an error? doesn't look like it's getting bubbled up.. Proxy sents up an error_bucket with HTTP_BAD_GATEWAY if the connection to the backend broke in the middle. Regards Rüdiger
Re: Mod_proxy_http ProxyErrorOverride eating cookies
Plüm wrote: > >> -Ursprüngliche Nachricht- >> Von: Bart van der Schans >> >> Hi, >> >> The "ProxyErrorOverride On" setting is correctly catching the errors >> from the (reverse) proxied server. Only, it overrides too much IMHO. >> Right now it overrides anything that's not in the 2xx range, >> but I think >> it should allow also the 3xx range for redirects etc. > > I had a quick look into this and noticed the following: > > 1. It may make sense to add ap_is_HTTP_INFO to this also. Yes, that shounds like a good idea. > 2. ProxyErrorOverride is currently only honoured by mod_proxy_http, >mod_proxy_ajp ignores it. Is this intended? I don't have much experience with ajp, but being able to set a custom error is a good idea I think. > 3. This is a change in behaviour for people who use customized redirect >pages for browsers that do not support redirects (are there any?) Wouldn't that change from currently broken to working? > 4. 304 not modified responses from the backend are currently not supported >without this patch. I didn't actually tested that. Regards, Bart > > Thoughts? > > Regards > > Rüdiger > -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
mod_http_proxy bug?
It looks like I'm getting some wierdness with http_proxy. it is not "returning" any error, but is giving back a 0 length bucket from apr_bucket_read when it should have some length. is there yet another way to check in a filter (ie, mod_cache stuff) if proxy had an error? doesn't look like it's getting bubbled up.. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: Mod_proxy_http ProxyErrorOverride eating cookies
> -Ursprüngliche Nachricht- > Von: Bart van der Schans > > Hi, > > The "ProxyErrorOverride On" setting is correctly catching the errors > from the (reverse) proxied server. Only, it overrides too much IMHO. > Right now it overrides anything that's not in the 2xx range, > but I think > it should allow also the 3xx range for redirects etc. I had a quick look into this and noticed the following: 1. It may make sense to add ap_is_HTTP_INFO to this also. 2. ProxyErrorOverride is currently only honoured by mod_proxy_http, mod_proxy_ajp ignores it. Is this intended? 3. This is a change in behaviour for people who use customized redirect pages for browsers that do not support redirects (are there any?) 4. 304 not modified responses from the backend are currently not supported without this patch. Thoughts? Regards Rüdiger
Mod_proxy_http ProxyErrorOverride eating cookies
Hi, The "ProxyErrorOverride On" setting is correctly catching the errors from the (reverse) proxied server. Only, it overrides too much IMHO. Right now it overrides anything that's not in the 2xx range, but I think it should allow also the 3xx range for redirects etc. A commonly used "trick" is to set a cookie with a 302 header so the browser gets redirected to the page which "needs" the cookie. When using ProxyErrorOverride, mod_proxy_http sets its own headers and the cookie is lost. The attached patch check not only for ap_is_HTTP_SUCCESS but also for ap_is_HTTP_REDIRECT which should solve the problem. Thanks, Bart van der Schans -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl -- --- httpd-2.2.0-orig/modules/proxy/mod_proxy_http.c 2005-11-10 16:20:05.0 +0100 +++ httpd-2.2.0/modules/proxy/mod_proxy_http.c 2006-03-31 18:02:26.0 +0200 @@ -1447,7 +1447,7 @@ * if we are overriding the errors, we can't put the content * of the page into the brigade */ -if (conf->error_override == 0 || ap_is_HTTP_SUCCESS(r->status)) { +if (conf->error_override == 0 || ap_is_HTTP_SUCCESS(r->status) || ap_is_HTTP_REDIRECT(r->status)) { /* read the body, pass it to the output filters */ apr_read_type_e mode = APR_NONBLOCK_READ; int finish = FALSE; @@ -1549,7 +1549,7 @@ if (conf->error_override) { /* the code above this checks for 'OK' which is what the hook expects */ -if (ap_is_HTTP_SUCCESS(r->status)) +if (ap_is_HTTP_SUCCESS(r->status) || ap_is_HTTP_REDIRECT(r->status)) return OK; else { /* clear r->status for override error, otherwise ErrorDocument
Re: svn commit: r391025 - /httpd/httpd/trunk/server/core.c
On 4/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: jim > Date: Mon Apr 3 05:10:22 2006 > New Revision: 391025 > > URL: http://svn.apache.org/viewcvs?rev=391025&view=rev > Log: > > We actually want to reach the rest of the code :) Thanks for cleaning up after me!!!
Re: svn commit: r390922 - in /httpd/httpd/trunk: CHANGES server/core.c
[EMAIL PROTECTED] wrote: > > --- httpd/httpd/trunk/server/core.c (original) > +++ httpd/httpd/trunk/server/core.c Sun Apr 2 16:36:27 2006 > @@ -3596,6 +3596,20 @@ > APR_BRIGADE_INSERT_TAIL(bb, e); > > return ap_pass_brigade(r->output_filters, bb); > +status = ap_pass_brigade(r->output_filters, bb); Certainly we want to remove the 'return ap_pass_brigade' line... :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: When did this break?
On Fri, Mar 31, 2006 at 03:23:11PM -0600, William Rowe wrote: > It seems this can be trivially solved by ensuring we defer this test until > after we invoke the sub-configure of apr and apr-util. The "sufficient version" test is currently only used if the sub-configure of ap[ru] is *not* invoked - when $apr_found is "yes", not "reconfig". "--with-apr=srclib/apr" actually treats the bundled sources like any "external" copy of APR, so must be already-configured at the time the httpd configure is run, AFAIK. If that's not happened, the apX-N-config file would not be found, so configure should fail earlier. What's really needed here is a "--with-included-apr"-type flag which forces use of the bundled sources over installed versions, rather than trying to overload --with-apr to do that. joe > William A. Rowe, Jr. wrote: > >./configure --with-apr=srclib/apr > > > >configure:5784: checking for APR version 1.2.0 or later > >conftest.c:20:25: apr_version.h: No such file or directory > >configure:5812: result: no > >configure:5818: error: APR version 1.2.0 or later is required > > > >This test is bogus because apr_version includes apr.h and that doesn't > >exist in a source-build tree. Why not test the file with awk? > > > >Bill > > > >. > > joe