Re: [VOTE] release 2.3.3 as alpha
On Wed, Nov 11, 2009 at 10:33 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: 2009/11/12 Paul Querna p...@querna.org: Test tarballs for Apache httpd 2.3.3-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/- 1 [ ] Release httpd-2.3.3 as Alpha Vote closes at 18:00 UTC on Sunday November 15 2009. Thanks, Paul What APR/APR-UTIL/PCRE versions are supposed to be used with this? Failing to build on MacOS X 10.5.8. Any modern 1.4.x APR should work. You can use the -deps version, by using '--with-included-apr' re: your build errors, it seems like your install of APR is kinda busted. I'd guess it must be too old, and something about the build system isn't picking up everyone correctly. Configure line: ./configure --prefix=/usr/local/apache-2.3 --with-apr=/usr/local/apr-1.4/bin/apr-1-config --with-apr-util=/usr/local/apr-util-1.4/bin/apu-1-config --with-pcre=/usr/local/pcre-8.00/bin/pcre-config Build error: /usr/local/apr-1.4/build-1/libtool --silent --mode=compile gcc -g -O2 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I. -I/Users/grahamd/Packages/httpd-2.3.3-alpha/os/unix -I/Users/grahamd/Packages/httpd-2.3.3-alpha/include -I/usr/local/apr-1.4/include/apr-1 -I/usr/local/apr-util-1.4/include/apr-1 -I/usr/local/pcre-8.00/include -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/aaa -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/cache -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/core -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/database -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/filters -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ldap -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/loggers -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/lua -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/proxy -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/session -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ssl -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/test -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/arch/unix -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/dav/main -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/generators -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/mappers -prefer-non-pic -static -c htpasswd.c touch htpasswd.lo /usr/local/apr-1.4/build-1/libtool --silent --mode=link gcc -g -O2 -o htpasswd htpasswd.lo /usr/local/apr-util-1.4/lib/libaprutil-1.la @LDADD_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv /usr/local/apr-1.4/lib/libapr-1.la -lpthread i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_db@: No such file or directory i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_gdbm@: No such file or directory i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_ndbm@: No such file or directory The config.log shows: AP_LIBS='$(MOD_AUTHN_FILE_LDADD) $(MOD_AUTHN_CORE_LDADD) $(MOD_AUTHZ_HOST_LDADD) $(MOD_AUTHZ_GROUPFILE_LDADD) $(MOD_AUTHZ_USER_LDADD) $(MOD_AUTHZ_CORE_LDADD) $(MOD_ACCESS_COMPAT_LDADD) $(MOD_AUTH_BASIC_LDADD) $(MOD_AUTH_FORM_LDADD) $(MOD_SO_LDADD) $(MOD_BUFFER_LDADD) $(MOD_RATELIMIT_LDADD) $(MOD_REQTIMEOUT_LDADD) $(MOD_REQUEST_LDADD) $(MOD_INCLUDE_LDADD) $(MOD_FILTER_LDADD) $(MOD_LOG_CONFIG_LDADD) $(MOD_ENV_LDADD) $(MOD_SETENVIF_LDADD) $(MOD_VERSION_LDADD) $(MOD_HTTP_LDADD) $(MOD_MIME_LDADD) $(MOD_UNIXD_LDADD) $(MOD_STATUS_LDADD) $(MOD_AUTOINDEX_LDADD) $(MOD_ASIS_LDADD) $(MOD_CGID_LDADD) $(MOD_NEGOTIATION_LDADD) $(MOD_DIR_LDADD) $(MOD_ACTIONS_LDADD) $(MOD_USERDIR_LDADD) $(MOD_ALIAS_LDADD) /usr/local/apr-util-1.4/lib/libaprutil-1.la �...@ldadd_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv /usr/local/apr-1.4/lib/libapr-1.la -lpthread' but no other mention of those non substituted values. The config.status just reflects same thing: S[AP_LIBS]=$(MOD_AUTHN_FILE_LDADD) $(MOD_AUTHN_CORE_LDADD) $(MOD_AUTHZ_HOST_LDADD) $(MOD_AUTHZ_GROUPFILE_LDADD) $(MOD_AUTHZ_USER_LDADD) $(MOD_AUTHZ_CORE_LDADD)\ $(MOD_ACCESS_COMPAT_LDADD) $(MOD_AUTH_BASIC_LDADD) $(MOD_AUTH_FORM_LDADD) $(MOD_SO_LDADD) $(MOD_BUFFER_LDADD) $(MOD_RATELIMIT_LDADD) $(MOD_REQTIMEO\ UT_LDADD) $(MOD_REQUEST_LDADD) $(MOD_INCLUDE_LDADD) $(MOD_FILTER_LDADD) $(MOD_LOG_CONFIG_LDADD) $(MOD_ENV_LDADD) $(MOD_SETENVIF_LDADD) $(MOD_VERSION\ _LDADD) $(MOD_HTTP_LDADD) $(MOD_MIME_LDADD) $(MOD_UNIXD_LDADD) $(MOD_STATUS_LDADD) $(MOD_AUTOINDEX_LDADD) $(MOD_ASIS_LDADD) $(MOD_CGID_LDADD) $(MOD_\ NEGOTIATION_LDADD) $(MOD_DIR_LDADD) $(MOD_ACTIONS_LDADD) $(MOD_USERDIR_LDADD) $(MOD_ALIAS_LDADD) /usr/local/apr-util-1.4/lib/libaprutil-1.la �...@ldad\ D_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv /usr/local/apr-1.4/lib/libapr-1.la -lpthread Had noticed this problem in subversion trunk couple of days before you rolled this tarball but didn't have a chance to post anything. If remove those values from build/config_vars.mk and continue build then stops with: /usr/local/apr-1.4/build-1/libtool --silent
Re: [VOTE] release 2.3.3 as alpha
2009/11/12 Paul Querna p...@querna.org: On Wed, Nov 11, 2009 at 10:33 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: 2009/11/12 Paul Querna p...@querna.org: Test tarballs for Apache httpd 2.3.3-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/- 1 [ ] Release httpd-2.3.3 as Alpha Vote closes at 18:00 UTC on Sunday November 15 2009. Thanks, Paul What APR/APR-UTIL/PCRE versions are supposed to be used with this? Failing to build on MacOS X 10.5.8. Any modern 1.4.x APR should work. You can use the -deps version, by using '--with-included-apr' Huh. There is no bundled APR/APR-UTIL in the alpha tarball, so how is --with-included-apr work going to work? re: your build errors, it seems like your install of APR is kinda busted. I'd guess it must be too old, and something about the build system isn't picking up everyone correctly. Or too new. It was actually the head from subversion versions of 1.4 for both APR and APR-UTIL. http://svn.apache.org/repos/asf/apr/apr/branches/1.4.x http://svn.apache.org/repos/asf/apr/apr-util/branches/1.4.x I'll try with last official tarballs of both instead. Graham Configure line: ./configure --prefix=/usr/local/apache-2.3 --with-apr=/usr/local/apr-1.4/bin/apr-1-config --with-apr-util=/usr/local/apr-util-1.4/bin/apu-1-config --with-pcre=/usr/local/pcre-8.00/bin/pcre-config Build error: /usr/local/apr-1.4/build-1/libtool --silent --mode=compile gcc -g -O2 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I. -I/Users/grahamd/Packages/httpd-2.3.3-alpha/os/unix -I/Users/grahamd/Packages/httpd-2.3.3-alpha/include -I/usr/local/apr-1.4/include/apr-1 -I/usr/local/apr-util-1.4/include/apr-1 -I/usr/local/pcre-8.00/include -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/aaa -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/cache -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/core -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/database -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/filters -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ldap -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/loggers -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/lua -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/proxy -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/session -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ssl -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/test -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/arch/unix -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/dav/main -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/generators -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/mappers -prefer-non-pic -static -c htpasswd.c touch htpasswd.lo /usr/local/apr-1.4/build-1/libtool --silent --mode=link gcc -g -O2 -o htpasswd htpasswd.lo /usr/local/apr-util-1.4/lib/libaprutil-1.la @LDADD_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv /usr/local/apr-1.4/lib/libapr-1.la -lpthread i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_db@: No such file or directory i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_gdbm@: No such file or directory i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_ndbm@: No such file or directory The config.log shows: AP_LIBS='$(MOD_AUTHN_FILE_LDADD) $(MOD_AUTHN_CORE_LDADD) $(MOD_AUTHZ_HOST_LDADD) $(MOD_AUTHZ_GROUPFILE_LDADD) $(MOD_AUTHZ_USER_LDADD) $(MOD_AUTHZ_CORE_LDADD) $(MOD_ACCESS_COMPAT_LDADD) $(MOD_AUTH_BASIC_LDADD) $(MOD_AUTH_FORM_LDADD) $(MOD_SO_LDADD) $(MOD_BUFFER_LDADD) $(MOD_RATELIMIT_LDADD) $(MOD_REQTIMEOUT_LDADD) $(MOD_REQUEST_LDADD) $(MOD_INCLUDE_LDADD) $(MOD_FILTER_LDADD) $(MOD_LOG_CONFIG_LDADD) $(MOD_ENV_LDADD) $(MOD_SETENVIF_LDADD) $(MOD_VERSION_LDADD) $(MOD_HTTP_LDADD) $(MOD_MIME_LDADD) $(MOD_UNIXD_LDADD) $(MOD_STATUS_LDADD) $(MOD_AUTOINDEX_LDADD) $(MOD_ASIS_LDADD) $(MOD_CGID_LDADD) $(MOD_NEGOTIATION_LDADD) $(MOD_DIR_LDADD) $(MOD_ACTIONS_LDADD) $(MOD_USERDIR_LDADD) $(MOD_ALIAS_LDADD) /usr/local/apr-util-1.4/lib/libaprutil-1.la �...@ldadd_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv /usr/local/apr-1.4/lib/libapr-1.la -lpthread' but no other mention of those non substituted values. The config.status just reflects same thing: S[AP_LIBS]=$(MOD_AUTHN_FILE_LDADD) $(MOD_AUTHN_CORE_LDADD) $(MOD_AUTHZ_HOST_LDADD) $(MOD_AUTHZ_GROUPFILE_LDADD) $(MOD_AUTHZ_USER_LDADD) $(MOD_AUTHZ_CORE_LDADD)\ $(MOD_ACCESS_COMPAT_LDADD) $(MOD_AUTH_BASIC_LDADD) $(MOD_AUTH_FORM_LDADD) $(MOD_SO_LDADD) $(MOD_BUFFER_LDADD) $(MOD_RATELIMIT_LDADD) $(MOD_REQTIMEO\ UT_LDADD) $(MOD_REQUEST_LDADD) $(MOD_INCLUDE_LDADD) $(MOD_FILTER_LDADD) $(MOD_LOG_CONFIG_LDADD) $(MOD_ENV_LDADD) $(MOD_SETENVIF_LDADD) $(MOD_VERSION\ _LDADD) $(MOD_HTTP_LDADD) $(MOD_MIME_LDADD) $(MOD_UNIXD_LDADD) $(MOD_STATUS_LDADD) $(MOD_AUTOINDEX_LDADD) $(MOD_ASIS_LDADD) $(MOD_CGID_LDADD) $(MOD_\ NEGOTIATION_LDADD) $(MOD_DIR_LDADD) $(MOD_ACTIONS_LDADD) $(MOD_USERDIR_LDADD) $(MOD_ALIAS_LDADD)
Re: [VOTE] release 2.3.3 as alpha
2009/11/12 Graham Dumpleton graham.dumple...@gmail.com: 2009/11/12 Paul Querna p...@querna.org: On Wed, Nov 11, 2009 at 10:33 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: 2009/11/12 Paul Querna p...@querna.org: Test tarballs for Apache httpd 2.3.3-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/- 1 [ ] Release httpd-2.3.3 as Alpha Vote closes at 18:00 UTC on Sunday November 15 2009. Thanks, Paul What APR/APR-UTIL/PCRE versions are supposed to be used with this? Failing to build on MacOS X 10.5.8. Any modern 1.4.x APR should work. You can use the -deps version, by using '--with-included-apr' Huh. There is no bundled APR/APR-UTIL in the alpha tarball, so how is --with-included-apr work going to work? re: your build errors, it seems like your install of APR is kinda busted. I'd guess it must be too old, and something about the build system isn't picking up everyone correctly. Or too new. It was actually the head from subversion versions of 1.4 for both APR and APR-UTIL. http://svn.apache.org/repos/asf/apr/apr/branches/1.4.x http://svn.apache.org/repos/asf/apr/apr-util/branches/1.4.x I'll try with last official tarballs of both instead. Hmmm, no tarballs. I tried trashing my APR/APR-UTIL install directories. Validated I was up to date from those subversion branches, which I was, did make distclean, ran configure again from scratch and reinstalled. Then tried rebuilding 2.3 again and still had same problem. Given that there are no 1.4 tarballs for APR/APR-UTIL, which subversion trunk/branch are you meant to use? Are the branches I used the correct thing to use. I noticed there was no trunk for apr-util: $ svn list http://svn.apache.org/repos/asf/apr/apr-util branches/ tags/ and since had to use branch for that, assumed was supposed to use branch for apr as well even though it has a trunk. $ svn list http://svn.apache.org/repos/asf/apr/apr/ branches/ tags/ trunk/ Graham Configure line: ./configure --prefix=/usr/local/apache-2.3 --with-apr=/usr/local/apr-1.4/bin/apr-1-config --with-apr-util=/usr/local/apr-util-1.4/bin/apu-1-config --with-pcre=/usr/local/pcre-8.00/bin/pcre-config Build error: /usr/local/apr-1.4/build-1/libtool --silent --mode=compile gcc -g -O2 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I. -I/Users/grahamd/Packages/httpd-2.3.3-alpha/os/unix -I/Users/grahamd/Packages/httpd-2.3.3-alpha/include -I/usr/local/apr-1.4/include/apr-1 -I/usr/local/apr-util-1.4/include/apr-1 -I/usr/local/pcre-8.00/include -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/aaa -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/cache -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/core -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/database -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/filters -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ldap -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/loggers -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/lua -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/proxy -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/session -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ssl -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/test -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/arch/unix -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/dav/main -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/generators -I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/mappers -prefer-non-pic -static -c htpasswd.c touch htpasswd.lo /usr/local/apr-1.4/build-1/libtool --silent --mode=link gcc -g -O2 -o htpasswd htpasswd.lo /usr/local/apr-util-1.4/lib/libaprutil-1.la @LDADD_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv /usr/local/apr-1.4/lib/libapr-1.la -lpthread i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_db@: No such file or directory i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_gdbm@: No such file or directory i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_ndbm@: No such file or directory The config.log shows: AP_LIBS='$(MOD_AUTHN_FILE_LDADD) $(MOD_AUTHN_CORE_LDADD) $(MOD_AUTHZ_HOST_LDADD) $(MOD_AUTHZ_GROUPFILE_LDADD) $(MOD_AUTHZ_USER_LDADD) $(MOD_AUTHZ_CORE_LDADD) $(MOD_ACCESS_COMPAT_LDADD) $(MOD_AUTH_BASIC_LDADD) $(MOD_AUTH_FORM_LDADD) $(MOD_SO_LDADD) $(MOD_BUFFER_LDADD) $(MOD_RATELIMIT_LDADD) $(MOD_REQTIMEOUT_LDADD) $(MOD_REQUEST_LDADD) $(MOD_INCLUDE_LDADD) $(MOD_FILTER_LDADD) $(MOD_LOG_CONFIG_LDADD) $(MOD_ENV_LDADD) $(MOD_SETENVIF_LDADD) $(MOD_VERSION_LDADD) $(MOD_HTTP_LDADD) $(MOD_MIME_LDADD) $(MOD_UNIXD_LDADD) $(MOD_STATUS_LDADD) $(MOD_AUTOINDEX_LDADD) $(MOD_ASIS_LDADD) $(MOD_CGID_LDADD) $(MOD_NEGOTIATION_LDADD) $(MOD_DIR_LDADD) $(MOD_ACTIONS_LDADD) $(MOD_USERDIR_LDADD) $(MOD_ALIAS_LDADD) /usr/local/apr-util-1.4/lib/libaprutil-1.la �...@ldadd_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv /usr/local/apr-1.4/lib/libapr-1.la -lpthread' but no other mention of
Re: [VOTE] release 2.3.3 as alpha
FWIW, the @??@ symbols are coming from apu-1-config because they are
never expanded by configure script for apr-util. Ie., snippet from
apu-1-config is:
LIBS=-lexpat -liconv
INCLUDES=
LDFLAGS=
LDAP_LIBS=
DBM_LIBS=@LDADD_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@
APRUTIL_LIBNAME=aprutil-${APRUTIL_MAJOR_VERSION}
APU_SOURCE_DIR=/Users/grahamd/Projects/apr-util-1.4-trunk
APU_BUILD_DIR=/Users/grahamd/Projects/apr-util-1.4-trunk
APR_XML_EXPAT_OLD=@APR_XML_EXPAT_OLD@
APU_DB_VERSION=0
This has occurred because autoconf hadn't been run to regenerate
configure script last time I updated from subversion.
Must of missed it. Remember to do it for apr. :-(
Trying again now.
Graham
2009/11/12 Graham Dumpleton graham.dumple...@gmail.com:
2009/11/12 Graham Dumpleton graham.dumple...@gmail.com:
2009/11/12 Paul Querna p...@querna.org:
On Wed, Nov 11, 2009 at 10:33 PM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
2009/11/12 Paul Querna p...@querna.org:
Test tarballs for Apache httpd 2.3.3-alpha are available at:
http://httpd.apache.org/dev/dist/
Your votes please;
+/- 1
[ ] Release httpd-2.3.3 as Alpha
Vote closes at 18:00 UTC on Sunday November 15 2009.
Thanks,
Paul
What APR/APR-UTIL/PCRE versions are supposed to be used with this?
Failing to build on MacOS X 10.5.8.
Any modern 1.4.x APR should work.
You can use the -deps version, by using '--with-included-apr'
Huh. There is no bundled APR/APR-UTIL in the alpha tarball, so how is
--with-included-apr work going to work?
re: your build errors, it seems like your install of APR is kinda
busted. I'd guess it must be too old, and something about the build
system isn't picking up everyone correctly.
Or too new. It was actually the head from subversion versions of 1.4
for both APR and APR-UTIL.
http://svn.apache.org/repos/asf/apr/apr/branches/1.4.x
http://svn.apache.org/repos/asf/apr/apr-util/branches/1.4.x
I'll try with last official tarballs of both instead.
Hmmm, no tarballs.
I tried trashing my APR/APR-UTIL install directories. Validated I was
up to date from those subversion branches, which I was, did make
distclean, ran configure again from scratch and reinstalled. Then
tried rebuilding 2.3 again and still had same problem.
Given that there are no 1.4 tarballs for APR/APR-UTIL, which
subversion trunk/branch are you meant to use?
Are the branches I used the correct thing to use. I noticed there was
no trunk for apr-util:
$ svn list http://svn.apache.org/repos/asf/apr/apr-util
branches/
tags/
and since had to use branch for that, assumed was supposed to use
branch for apr as well even though it has a trunk.
$ svn list http://svn.apache.org/repos/asf/apr/apr/
branches/
tags/
trunk/
Graham
Configure line:
./configure --prefix=/usr/local/apache-2.3
--with-apr=/usr/local/apr-1.4/bin/apr-1-config
--with-apr-util=/usr/local/apr-util-1.4/bin/apu-1-config
--with-pcre=/usr/local/pcre-8.00/bin/pcre-config
Build error:
/usr/local/apr-1.4/build-1/libtool --silent --mode=compile gcc -g -O2
-DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I.
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/os/unix
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/include
-I/usr/local/apr-1.4/include/apr-1
-I/usr/local/apr-util-1.4/include/apr-1 -I/usr/local/pcre-8.00/include
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/aaa
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/cache
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/core
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/database
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/filters
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ldap
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/loggers
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/lua
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/proxy
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/session
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ssl
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/test
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/arch/unix
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/dav/main
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/generators
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/mappers
-prefer-non-pic -static -c htpasswd.c touch htpasswd.lo
/usr/local/apr-1.4/build-1/libtool --silent --mode=link gcc -g -O2
-o htpasswd htpasswd.lo
/usr/local/apr-util-1.4/lib/libaprutil-1.la @LDADD_dbm_db@
@LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@ -lexpat -liconv
/usr/local/apr-1.4/lib/libapr-1.la -lpthread
i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_db@: No such file or directory
i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_gdbm@: No such file or directory
i686-apple-darwin9-gcc-4.0.1: @LDADD_dbm_ndbm@: No such file or directory
The config.log shows:
AP_LIBS='$(MOD_AUTHN_FILE_LDADD) $(MOD_AUTHN_CORE_LDADD)
$(MOD_AUTHZ_HOST_LDADD) $(MOD_AUTHZ_GROUPFILE_LDADD)
$(MOD_AUTHZ_USER_LDADD)
Re: [VOTE] release 2.3.3 as alpha
2009/11/12 Graham Dumpleton graham.dumple...@gmail.com:
FWIW, the @??@ symbols are coming from apu-1-config because they are
never expanded by configure script for apr-util. Ie., snippet from
apu-1-config is:
LIBS=-lexpat -liconv
INCLUDES=
LDFLAGS=
LDAP_LIBS=
DBM_LIBS=@LDADD_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@
APRUTIL_LIBNAME=aprutil-${APRUTIL_MAJOR_VERSION}
APU_SOURCE_DIR=/Users/grahamd/Projects/apr-util-1.4-trunk
APU_BUILD_DIR=/Users/grahamd/Projects/apr-util-1.4-trunk
APR_XML_EXPAT_OLD=@APR_XML_EXPAT_OLD@
APU_DB_VERSION=0
This has occurred because autoconf hadn't been run to regenerate
configure script last time I updated from subversion.
Must of missed it. Remember to do it for apr. :-(
Trying again now.
Get past the problem with @??@ variables, but still get linking issues with:
/usr/local/apr-1.4/build-1/libtool --silent --mode=link gcc -g -O2
-o ab ab.lo
/usr/local/apr-util-1.4/lib/libaprutil-1.la -lexpat -liconv
/usr/local/apr-1.4/lib/libapr-1.la -lpthread
Undefined symbols:
_apr_pollset_create, referenced from:
_main in ab.o
_apr_pollset_remove, referenced from:
_set_conn_state in ab.o
_apr_pollset_poll, referenced from:
_main in ab.o
_apr_pollset_add, referenced from:
_set_conn_state in ab.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
There are undefined references to them in libapr, but no actual code for it.
No more time to look at it today.
Graham
2009/11/12 Graham Dumpleton graham.dumple...@gmail.com:
2009/11/12 Graham Dumpleton graham.dumple...@gmail.com:
2009/11/12 Paul Querna p...@querna.org:
On Wed, Nov 11, 2009 at 10:33 PM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
2009/11/12 Paul Querna p...@querna.org:
Test tarballs for Apache httpd 2.3.3-alpha are available at:
http://httpd.apache.org/dev/dist/
Your votes please;
+/- 1
[ ] Release httpd-2.3.3 as Alpha
Vote closes at 18:00 UTC on Sunday November 15 2009.
Thanks,
Paul
What APR/APR-UTIL/PCRE versions are supposed to be used with this?
Failing to build on MacOS X 10.5.8.
Any modern 1.4.x APR should work.
You can use the -deps version, by using '--with-included-apr'
Huh. There is no bundled APR/APR-UTIL in the alpha tarball, so how is
--with-included-apr work going to work?
re: your build errors, it seems like your install of APR is kinda
busted. I'd guess it must be too old, and something about the build
system isn't picking up everyone correctly.
Or too new. It was actually the head from subversion versions of 1.4
for both APR and APR-UTIL.
http://svn.apache.org/repos/asf/apr/apr/branches/1.4.x
http://svn.apache.org/repos/asf/apr/apr-util/branches/1.4.x
I'll try with last official tarballs of both instead.
Hmmm, no tarballs.
I tried trashing my APR/APR-UTIL install directories. Validated I was
up to date from those subversion branches, which I was, did make
distclean, ran configure again from scratch and reinstalled. Then
tried rebuilding 2.3 again and still had same problem.
Given that there are no 1.4 tarballs for APR/APR-UTIL, which
subversion trunk/branch are you meant to use?
Are the branches I used the correct thing to use. I noticed there was
no trunk for apr-util:
$ svn list http://svn.apache.org/repos/asf/apr/apr-util
branches/
tags/
and since had to use branch for that, assumed was supposed to use
branch for apr as well even though it has a trunk.
$ svn list http://svn.apache.org/repos/asf/apr/apr/
branches/
tags/
trunk/
Graham
Configure line:
./configure --prefix=/usr/local/apache-2.3
--with-apr=/usr/local/apr-1.4/bin/apr-1-config
--with-apr-util=/usr/local/apr-util-1.4/bin/apu-1-config
--with-pcre=/usr/local/pcre-8.00/bin/pcre-config
Build error:
/usr/local/apr-1.4/build-1/libtool --silent --mode=compile gcc -g -O2
-DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I.
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/os/unix
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/include
-I/usr/local/apr-1.4/include/apr-1
-I/usr/local/apr-util-1.4/include/apr-1 -I/usr/local/pcre-8.00/include
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/aaa
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/cache
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/core
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/database
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/filters
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ldap
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/loggers
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/lua
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/proxy
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/session
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/ssl
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/test
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/arch/unix
-I/Users/grahamd/Packages/httpd-2.3.3-alpha/modules/dav/main
Re: dav_new_error_*() and errno, revisit before 2.4 GA
On Wed, Nov 11, 2009 at 10:06 PM, Greg Stein gst...@gmail.com wrote:
On Wed, Nov 11, 2009 at 20:09, Jeff Trawick traw...@gmail.com wrote:
On Wed, Nov 11, 2009 at 6:58 PM, Greg Stein gst...@gmail.com wrote:
On Wed, Nov 11, 2009 at 17:11, Jeff Trawick traw...@gmail.com wrote:
At present, whatever was in errno at the time the dav_error {} was
created is treated as an apr_status_t by ap_log_rerror().
http://mail-archives.apache.org/mod_mbox/httpd-dev/200211.mbox/%3c20021101033848.b29...@lyra.org%3e
dav_error {} should have an apr_status_t field instead of an errno
field; functions which create a dav_error should have an apr_status_t
parameter.
If there's no direct apr_status_t representation of the error, the
caller will have to decide what to do (no magic portable solution
AFAIK, but no worse than today).
Concerns?
dav_error was designed during the 1.3 series. APR wasn't even being
discussed. So yeah... there is definitely a disconnect from then to
now.
I'd be quite supportive of changing that, though (strictly speaking)
that is probably an API change.
well, yes it is an API change ;) I think the issue is whether or not
you in the DAV community want to push it on your third-party
colleagues.
A third-party mod could define something like this for compatibility:
#if AP_MODULE_MAGIC_AT_LEAST(xxx,y)
#define foo_dav_new_error(p, stat, errid, rv, desc) \
dav_new_error(p, stat, errid, rv, desc)
#else
#define foo_dav_new_error(p, stat, errid, rv, desc) \
(errno = (rv), \
dav_new_error(p, stat, errid, desc))
#endif
and go ahead and change its code to pass in an apr_status_t.
If it is too ugly to force this on third-party modules, we'll need to
add new APIs and use those ourselves, as it is too ugly for us to keep
mismanaging the error codes.
I have no opinion in this space. I'm very much out of touch nowadays
with the mod_dav users/community. The one particular user of mod_dav
that I'm concerned with is mod_dav_svn, and *that* is about to become
an Apache project :-)
svn can certainly use that macro. You get to measure the disruption
to other API users of Apache.
Other folks will just have to recompile to accommodate the new MMN.
That has to be okay for pre-GA.
Posting a heads-up rough patch to dav lists for other DAV modules will help.
In fact, we floated the idea of whether mod_dav_svn can/should be
transferred over to httpd, rather than maintained as part of svn.
Total random comment, but a couple people went hmm It would be
kinda neat for any Apache server to have built-in support for svn :-)
shrug
(and would solve a bunch of versioning combinatorics for svn...)
sure
--/--
I'll post an errno-apr_status_t patch in the next day or two.
Re: Httpd 3.0 or something else
On Nov 11, 2009, at 2:14 PM, Akins, Brian wrote: On 11/10/09 6:20 PM, Greg Stein gst...@gmail.com wrote: I'd like to see a few network threads multiplexing all the writing to clients. That's what I meant. I just didn't state it properly. Then take all of *that*, and spread it across several processes for solid uptime, with a master monitor process. And then you have nginx ;) Well, nginx is, after all, a fork of httpd
Re: Obsolete modules in 2.3
On Nov 11, 2009, at 23:21 , William A. Rowe Jr. wrote: Rich Bowen wrote: Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta? there is already a large number of CERN users who can exploit this module. Seriously? LOL FWIW I know of one customer who absolutely continues to use mod_imagemap and have no indication they plan to drop it. modules/historical/ might be a good waypoint to eliminating these. Enabling them should emit a warning they are no longer interesting and likely to be dropped from future releases. OTOH perhaps we should keep cern_meta, considering the underlying argument from fans of over-aggressive content-type sniffing always cite broken httpd configs as the reason for their sillyness. As a non-scientific data point, I have never encountered anybody who knows what mod_imagemap does, in all the years that I've been doing Apache training. And in the 2.0-and-before days, when I would mention mod_imap, the response would ALWAYS be Apache does IMAP? Really? Also, I have asked on users@ who uses it, and received one response so far, saying that they hadn't heard of it until my question, and had to go look it up. Anyone who is using SERVER-SIDE image maps needs to upgrade to Netscape version 1.4 or later (circa 1992), which does client-side image maps. Bill, seriously, you need to tell your customer that HTML 2 added support for client-side image maps. It's 2009 now. As for mod_cern_meta, if one insists on keeping it, perhaps rename it to something less archaic, and perhaps merging it with mod_asis to produce something actually useful. But, truly, finding people who have even *heard* of the CERN web server is getting harder, and providing backward compat with it is simply laughable. -- Rich Bowen rbo...@rcbowen.com
Re: Obsolete modules in 2.3
On Thu, Nov 12, 2009 at 9:08 AM, Rich Bowen rbo...@rcbowen.com wrote: As a non-scientific data point, I have never encountered anybody who knows what mod_imagemap does, in all the years that I've been doing Apache training. And in the 2.0-and-before days, when I would mention mod_imap, the response would ALWAYS be Apache does IMAP? Really? Also, I have asked on users@ who uses it, and received one response so far, saying that they hadn't heard of it until my question, and had to go look it up. Aside from CVE queries, haven't heard a peep in years on IRC/users@ or even at $bigco. Maybe it's just our best, most well-documented module though :) -- Eric Covener cove...@gmail.com
pipe has been ended. : mod_fcgid: get overlap result error
Hello, Please help, what am I doing wrong? I can't get the example to work from http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html Thanks! Brian Error.log contains: [Wed Nov 11 15:57:27 2009] [warn] [client 192.168.21.21] (OS 109)The pipe has been ended. : mod_fcgid: get overlap result error [Wed Nov 11 15:57:27 2009] [error] [client 192.168.21.21] Premature end of script headers: foo.pl foo.pl is from: http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html Software versions: 1. mod_fcgid-2.3.4-win32-x86.zip 2. apache_2.2.14-win32-x86-openssl-0.9.8k.msi 3. Windows Server 2003 R2 Httpd.conf entries: LoadModule fcgid_module modules/mod_fcgid.so Alias /fcgi-bin/ C:/Apache/fcgi-bin/ IfModule fcgid_module FcgidConnectTimeout 20 FcgidIOTimeout 48 /IfModule # Directives from http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html Directory C:/Apache/fcgi-bin SetHandler fcgid-script Options +ExecCGI # Customize the next two directives for your requirements. Order allow,deny Allow from all /Directory
Re: Httpd 3.0 or something else
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Greg Stein wrote: Apache remains the broad solution, but for narrow requirements, people will select something that is easier to handle for their particular situation. I wouldn't say wrong, but more along the lines of not as well-suited I partially agree, but we have to take into account that some of those httpd's, like lighttpd, are replacing Apache plain and simple. Don't get me wrong. I love Apache. I've written tons of articles about it since the very early days. And I haven't released any mod_openpgp code for any other thing other than Apache for a reason: i love it. - -- Arturo Buanzo Busleiman Independent Linux and Security Consultant - OWASP - SANS - OISSG http://www.buanzo.com.ar/pro/eng.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkr8Is4ACgkQAlpOsGhXcE1tFwCdEAEZQDVG9c2yNXwYBk2/ VgIAn2emSNcp1xwXa2bxgoK09JKMcsV4 =T/Fe -END PGP SIGNATURE-
Re: Obsolete modules in 2.3
(another user's perspective) At my work (US. Geological Survey) we try to discourage webmasters from using server-side imagemaps, since they are not Section 508 compliant. We've had to keep the module to support some legacy sites, but if 2.4 drops it, we can probably migrate any remaining server-side maps. - Ken On Thu, Nov 12, 2009 at 7:29 AM, Eric Covener cove...@gmail.com wrote: On Thu, Nov 12, 2009 at 9:08 AM, Rich Bowen rbo...@rcbowen.com wrote: As a non-scientific data point, I have never encountered anybody who knows what mod_imagemap does, in all the years that I've been doing Apache training. And in the 2.0-and-before days, when I would mention mod_imap, the response would ALWAYS be Apache does IMAP? Really? Also, I have asked on users@ who uses it, and received one response so far, saying that they hadn't heard of it until my question, and had to go look it up. Aside from CVE queries, haven't heard a peep in years on IRC/users@ or even at $bigco. Maybe it's just our best, most well-documented module though :) -- Eric Covener cove...@gmail.com
Re: Httpd 3.0 or something else
On Thu, Nov 12, 2009 at 09:59, Arturo 'Buanzo' Busleiman bua...@buanzo.com.ar wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Greg Stein wrote: Apache remains the broad solution, but for narrow requirements, people will select something that is easier to handle for their particular situation. I wouldn't say wrong, but more along the lines of not as well-suited I partially agree, but we have to take into account that some of those httpd's, like lighttpd, are replacing Apache plain and simple. Don't get me wrong. I love Apache. I've written tons of articles about it since the very early days. And I haven't released any mod_openpgp code for any other thing other than Apache for a reason: i love it. Yeah... I think we're in agreement. I'm just trying to say those aren't necessarily *better* than Apache, but that they are *better-suited* to their admin's scenarios. As the swiss army knife of web servers, Apache is very heavy in the pocket. In many scenarios, one little blade is all you need, and it is much easier to use and maintain. I'm not sure that is a solvable problem for us, unfortunately. We would need a drastic overhaul of how we approach configuration. (not to mention setup/building and module loading/handling) In essence, I think the project has concentrated on backwards-compat rather than an overhaul for usability. Cheers, -g
Re: Obsolete modules in 2.3
On Thu, 12 Nov 2009, Eric Covener wrote:
On Thu, Nov 12, 2009 at 9:08 AM, Rich Bowen rbo...@rcbowen.com wrote:
As a non-scientific data point, I have never encountered anybody who knows
what mod_imagemap does, in all the years that I've been doing Apache
training. And in the 2.0-and-before days, when I would mention mod_imap, the
response would ALWAYS be Apache does IMAP? Really? Also, I have asked on
users@ who uses it, and received one response so far, saying that they
hadn't heard of it until my question, and had to go look it up.
Aside from CVE queries, haven't heard a peep in years on IRC/users@ or
even at $bigco.
Maybe it's just our best, most well-documented module though :)
So drop the confusing example module instead? Or has it been fixed
lately? ;)
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | ni...@acc.umu.se
---
It's as bad as you think and they are out to get you.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Obsolete modules in 2.3
Ken Dreyer wrote: (another user's perspective) At my work (US. Geological Survey) we try to discourage webmasters from using server-side imagemaps, since they are not Section 508 compliant. We've had to keep the module to support some legacy sites, but if 2.4 drops it, we can probably migrate any remaining server-side maps. Hmmm. When I worked alongside some of your folks (joint project - I was at ESRIN) we used server-side imagemaps to let users select points on a (geographical) map. Any user without the map could enter lat/long manually instead, and any clientside solution (like scripting, or embedded java/flash) would raise more serious accessibility problems (you'd want the serverside map as a fallback for accessibility)! OTOH, that used CERN HTTPD with CGI, not mod_imagemap. Don't you have that kind of application any more? -- Nick Kew
Re: Httpd 3.0 or something else
Greg Stein wrote: we have to take into account that some of those httpd's, like lighttpd, are replacing Apache plain and simple. [...] [...] I'm just trying to say those aren't necessarily*better* than Apache, but that they are *better-suited* to their admin's scenarios.[...] Last time I've heard about a large scale server thinking about switching from Apache to lighttpd, the one problem that site wanted to solve was a massive number slow clients simultaneously connected to the server, with the http server mostly just serving as a pipe between the client and php, and where the ideal solution had to consume as little resource per client as possible. Did the admin of that site just miss what the solution should have been to handle this properly with Apache ?
Re: Obsolete modules in 2.3
On Thu, Nov 12, 2009 at 11:27, Rich Bowen rbo...@rcbowen.com wrote: On Nov 12, 2009, at 11:12 , Nick Kew wrote: Ken Dreyer wrote: (another user's perspective) At my work (US. Geological Survey) we try to discourage webmasters from using server-side imagemaps, since they are not Section 508 compliant. We've had to keep the module to support some legacy sites, but if 2.4 drops it, we can probably migrate any remaining server-side maps. Hmmm. When I worked alongside some of your folks (joint project - I was at ESRIN) we used server-side imagemaps to let users select points on a (geographical) map. Any user without the map could enter lat/long manually instead, and any clientside solution (like scripting, or embedded java/flash) would raise more serious accessibility problems (you'd want the serverside map as a fallback for accessibility)! Client-side image maps have been part of HTML for more than a decade. It does not require any kind of scripting, java, flash, or javascript. If the map can be encoded in a way that mod_imagemap understands, you simply take that map data and put it directly in the HTML. The format is the same. If the map is complex enough that you can't encode it in a simple text map file, then mod_imagemap wouldn't help anyways, and you'd need a custom solution. Forcing a round-trip to the server, rather than putting the map data in the HTML, doesn't make any sense. mod_imagemap doesn't offer *any* features that aren't included in the HTML implementation. Even Lynx supports client-side imagemaps. And client-side imagemaps are completely accessible, if you do the map right, with comments. Lynx even provides a menu of the options in the imagemap, along with their titles/comments. Just torch it. No need to discuss. -g
Performance tuning documentation
The performance tuning documentation that we currently include in the docs is simply awful. What with the comments about Apache 1.2 and the suggestions of how to deal with the new Linux 2.0 kernel, I think it's beyond fixing. It needs to be tossed and rewritten - although perhaps there are parts that are salvageable. I was wondering if someone has a performance doc that they could contribute as a starting place? Perhaps Sander's talk from AC? Or if someone would be willing to give some attention to the docs list for a while to assist in writing something that would be useful to actual admins in the real world. -- Rich Bowen rbo...@rcbowen.com
Re: Obsolete modules in 2.3
On Nov 12, 2009, at 11:12 , Nick Kew wrote: Ken Dreyer wrote: (another user's perspective) At my work (US. Geological Survey) we try to discourage webmasters from using server-side imagemaps, since they are not Section 508 compliant. We've had to keep the module to support some legacy sites, but if 2.4 drops it, we can probably migrate any remaining server- side maps. Hmmm. When I worked alongside some of your folks (joint project - I was at ESRIN) we used server-side imagemaps to let users select points on a (geographical) map. Any user without the map could enter lat/long manually instead, and any clientside solution (like scripting, or embedded java/flash) would raise more serious accessibility problems (you'd want the serverside map as a fallback for accessibility)! Client-side image maps have been part of HTML for more than a decade. It does not require any kind of scripting, java, flash, or javascript. If the map can be encoded in a way that mod_imagemap understands, you simply take that map data and put it directly in the HTML. The format is the same. If the map is complex enough that you can't encode it in a simple text map file, then mod_imagemap wouldn't help anyways, and you'd need a custom solution. Forcing a round-trip to the server, rather than putting the map data in the HTML, doesn't make any sense. mod_imagemap doesn't offer *any* features that aren't included in the HTML implementation. Even Lynx supports client-side imagemaps. And client-side imagemaps are completely accessible, if you do the map right, with comments. Lynx even provides a menu of the options in the imagemap, along with their titles/comments. -- Rich Bowen rbo...@rcbowen.com
Re: Obsolete modules in 2.3
On Thu, Nov 12, 2009 at 9:12 AM, Nick Kew n...@webthing.com wrote: OTOH, that used CERN HTTPD with CGI, not mod_imagemap. Wow, old school :) Don't you have that kind of application any more? We definitely have a lot of interactive maps, but the processing you describe is usually handled by CGI or Java. Our only use of mod_imagemap that I have seen was for a website's navigation bar. On Thu, Nov 12, 2009 at 9:27 AM, Rich Bowen rbo...@rcbowen.com wrote: Client-side image maps have been part of HTML for more than a decade. It does not require any kind of scripting, java, flash, or javascript. Indeed, and client-side imagemaps are what we recommend to our webmasters to replace mod_imagemap (as do the Section 508 guidelines). On Thu, Nov 12, 2009 at 9:30 AM, Greg Stein gst...@gmail.com wrote: Just torch it. No need to discuss. Strike the match, as far as I'm concerned!
Re: Httpd 3.0 or something else
Jean-Marc Desperrier wrote: Last time I've heard about a large scale server thinking about switching from Apache to lighttpd, the one problem that site wanted to solve was a massive number slow clients simultaneously connected to the server, with the http server mostly just serving as a pipe between the client and php, and where the ideal solution had to consume as little resource per client as possible. Did the admin of that site just miss what the solution should have been to handle this properly with Apache ? Dedicated reverse proxy servers like varnish have appeared to solve this problem, and apparently work quite well for the narrow problem they are designed to solve (I say apparently because we're still at the evaluate stage on this). I would prefer in the long term that the two-layered approach wasn't necessary, which is why I am so keen to make sure httpd v3.0's architecture can optionally do what varnish does out of the box. Regards, Graham --
Re: [VOTE] release 2.3.3 as alpha
On Thu, Nov 12, 2009 at 3:22 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
2009/11/12 Graham Dumpleton graham.dumple...@gmail.com:
FWIW, the @??@ symbols are coming from apu-1-config because they are
never expanded by configure script for apr-util. Ie., snippet from
apu-1-config is:
LIBS=-lexpat -liconv
INCLUDES=
LDFLAGS=
LDAP_LIBS=
DBM_LIBS=@LDADD_dbm_db@ @LDADD_dbm_gdbm@ @LDADD_dbm_ndbm@
APRUTIL_LIBNAME=aprutil-${APRUTIL_MAJOR_VERSION}
APU_SOURCE_DIR=/Users/grahamd/Projects/apr-util-1.4-trunk
APU_BUILD_DIR=/Users/grahamd/Projects/apr-util-1.4-trunk
APR_XML_EXPAT_OLD=@APR_XML_EXPAT_OLD@
APU_DB_VERSION=0
This has occurred because autoconf hadn't been run to regenerate
configure script last time I updated from subversion.
Must of missed it. Remember to do it for apr. :-(
Trying again now.
Get past the problem with @??@ variables, but still get linking issues with:
/usr/local/apr-1.4/build-1/libtool --silent --mode=link gcc -g -O2
-o ab ab.lo
/usr/local/apr-util-1.4/lib/libaprutil-1.la -lexpat -liconv
/usr/local/apr-1.4/lib/libapr-1.la -lpthread
Undefined symbols:
_apr_pollset_create, referenced from:
_main in ab.o
_apr_pollset_remove, referenced from:
_set_conn_state in ab.o
_apr_pollset_poll, referenced from:
_main in ab.o
_apr_pollset_add, referenced from:
_set_conn_state in ab.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
There are undefined references to them in libapr, but no actual code for it.
Maybe forgot to run buildconf configure?
How those symbols are built changed in 1.4.x, but it still seems like
a build issue that they aren't getting linked in.
Anyways -- there is the httpd-2.3.3-alpha-deps tarballs -- those is
what I was referring to as bundled, and are the versions of
apr/apr-util i used when testing.
Re: pipe has been ended. : mod_fcgid: get overlap result error
On Thu, Nov 12, 2009 at 9:50 AM, Brian Kodl bk...@yahoo.com wrote: Hello, Please help, what am I doing wrong? I can't get the example to work from http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html Thanks! Brian Error.log contains: [Wed Nov 11 15:57:27 2009] [warn] [client 192.168.21.21] (OS 109)The pipe has been ended. : mod_fcgid: get overlap result error [Wed Nov 11 15:57:27 2009] [error] [client 192.168.21.21] Premature end of script headers: foo.pl I'd guess this is related to the shebang line processing, and that foo.plisn't getting started. Is the path to perl correct in foo.pl (maybe it should be #!/perl/bin/perl)? Do you need ScriptInterpreterSource registry to tie .pl files to the Perl interpreter, ignoring the shebang line?
Re: [VOTE] release 2.3.3 as alpha
On Nov 11, 2009, at 2:54 PM, Paul Querna wrote: Test tarballs for Apache httpd 2.3.3-alpha are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/- 1 [ ] Release httpd-2.3.3 as Alpha Vote closes at 18:00 UTC on Sunday November 15 2009. With OS X 10.6.x, works OK as long as one forces either -arch i386 or x86_64... But mod_ssl refuses to build (OpenSSL version foolishness). As such, I think this forces a -1
Re: pipe has been ended. : mod_fcgid: get overlap result error
Hi Jeff,
Thanks for your response! Yes, the path to perl is correct.
If I change the path to a bad location, then the error.log has this different
error:
[Thu Nov 12 12:55:48 2009] [error] (OS 3)The system cannot find the path
specified. : mod_fcgid: can't create process
[Thu Nov 12 12:55:48 2009] [warn] (OS 3)The system cannot find the path
specified. : mod_fcgid: spawn process c:/perl/bin2/perl.exe error
Here is foo.pl
#!c:/perl/bin/perl.exe
use CGI::Fast;
while (my $q = CGI::Fast-new) {
print(Content-Type: text/plain\n\n);
foreach $var (sort(keys(%ENV))) {
$val = $ENV{$var};
$val =~ s|\n|\\n|g;
$val =~ s||\\|g;
print ${var}=\${val}\\n;
}
}
Thanks!
Brian
--- On Thu, 11/12/09, Jeff Trawick traw...@gmail.com wrote:
From: Jeff Trawick traw...@gmail.com
Subject: Re: pipe has been ended. : mod_fcgid: get overlap result error
To: dev@httpd.apache.org
Date: Thursday, November 12, 2009, 12:34 PM
On Thu, Nov 12, 2009 at 9:50 AM, Brian Kodl bk...@yahoo.com wrote:
Hello,
Please help, what am I doing wrong? I can't get the example to work from
http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
Thanks!
Brian
Error.log contains:
[Wed Nov 11 15:57:27 2009] [warn] [client 192.168.21.21] (OS 109)The pipe has
been ended. : mod_fcgid: get overlap result error
[Wed Nov 11 15:57:27 2009] [error] [client 192.168.21.21] Premature end of
script headers: foo.pl
I'd guess this is related to the shebang line processing, and that foo.pl isn't
getting started.
Is the path to perl correct in foo.pl (maybe it should be #!/perl/bin/perl)?
Do you need ScriptInterpreterSource registry to tie .pl files to the Perl
interpreter, ignoring the shebang line?
Re: [VOTE] release 2.3.3 as alpha
Graham Dumpleton wrote: Are the branches I used the correct thing to use. yes. I noticed there was no trunk for apr-util: $ svn list http://svn.apache.org/repos/asf/apr/apr-util branches/ tags/ and since had to use branch for that, assumed was supposed to use branch for apr as well even though it has a trunk. $ svn list http://svn.apache.org/repos/asf/apr/apr/ branches/ tags/ trunk/ Trunk APR 2.0 should also work; there is no more apr-util. The config system, last I recall, will build with a uniary apr 2.0 (do not specify apr-util). Branched apr-util is not compatible with apr trunk.
Re: Obsolete modules in 2.3
Rich Bowen wrote: As for mod_cern_meta, if one insists on keeping it, perhaps rename it to something less archaic, and perhaps merging it with mod_asis to produce something actually useful. But, truly, finding people who have even *heard* of the CERN web server is getting harder, and providing backward compat with it is simply laughable. mod_mime_metafile or something sensible like that?
Re: svn commit: r835406 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_pm_main.c fcgid_proc_unix.c fcgid_proc_win.c fcgid_proctbl.h mod_fcgid.c
On Thu, Nov 12, 2009 at 10:05 AM, p...@apache.org wrote: Author: pqf Date: Thu Nov 12 15:05:08 2009 New Revision: 835406 URL: http://svn.apache.org/viewvc?rev=835406view=rev Log: Add fcgid extension to mod_status Hi Ryan, This looks extremely useful. Hopefully I can look at it more over the next few days. At first glance I think the process heading needs more information, such as the vhost or other attributes that distinguish the table from other tables for the same executable file, since otherwise it may be unexpected to see multiple tables for the same program, each with its own set of processes. For anyone that wants a quick look at the information, I've uploaded a sample page to http://people.apache.org/~trawick/mod_fcgid_status.html Thanks! BTW, I made some code formatting changes in r835540 to bring the new mod_status code closer to httpd project style (guidelines are at http://httpd.apache.org/dev/styleguide.html, examples for issues not covered there are throughout httpd).
Re: [VOTE] release 2.3.3 as alpha
Gregg L. Smith wrote: Sorry bout that, I always try first with VS6 SP6 SDK 2003R2 William A. Rowe Jr. wrote: Gregg L. Smith wrote: Generating Code... socket_util.c E:\build\httpd-2.3.3-alpha\srclib\apr\network_io\unix\socket_util.c(21) : error C2373: 'apr_socket_atreadeof' : redefinition; different type modifiers ./include\apr_network_io.h(362) : see declaration of 'apr_socket_atreadeof' We are missing a ton of information here; what VisualStudio and VC This on the surface seems misplaced. There is only one function in the offending file (socket_util.c), apr_status_t apr_socket_atreadeof(apr_socket_t *sock, int *atreadeof) That function is only called from testsock.c, unless I manually include either testlib or testdll or both projects, testsock.c is never compiled and therefore this function is never called as well. Should this not then be moved out of libapr.dsp and into those two 'test' projects? Gregg
Re: pipe has been ended. : mod_fcgid: get overlap result error
Ps - Is there a debug or trace httpd.conf directive to get more information?
--- On Thu, 11/12/09, Brian Kodl bk...@yahoo.com wrote:
From: Brian Kodl bk...@yahoo.com
Subject: Re: pipe has been ended. : mod_fcgid: get overlap result error
To: dev@httpd.apache.org
Date: Thursday, November 12, 2009, 1:00 PM
Hi Jeff,
Thanks for your response! Yes, the path to perl is correct.
If I change the path to a bad location, then the error.log has this different
error:
[Thu Nov 12 12:55:48 2009] [error] (OS 3)The system cannot find the path
specified. : mod_fcgid: can't create process
[Thu Nov 12 12:55:48 2009] [warn] (OS 3)The system cannot find the path
specified. : mod_fcgid: spawn process c:/perl/bin2/perl.exe error
Here is foo.pl
#!c:/perl/bin/perl.exe
use CGI::Fast;
while (my $q = CGI::Fast-new) {
print(Content-Type: text/plain\n\n);
foreach $var (sort(keys(%ENV))) {
$val = $ENV{$var};
$val =~ s|\n|\\n|g;
$val =~ s||\\|g;
print ${var}=\${val}\\n;
}
}
Thanks!
Brian
--- On Thu, 11/12/09, Jeff Trawick traw...@gmail.com wrote:
From: Jeff Trawick traw...@gmail.com
Subject: Re: pipe has been ended. : mod_fcgid: get overlap result error
To: dev@httpd.apache.org
Date: Thursday, November 12, 2009, 12:34 PM
On Thu, Nov 12, 2009 at 9:50 AM, Brian Kodl bk...@yahoo.com wrote:
Hello,
Please help, what am I doing wrong? I can't get the example to work from
http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
Thanks!
Brian
Error.log contains:
[Wed Nov 11 15:57:27 2009] [warn] [client 192.168.21.21] (OS 109)The pipe has
been ended. : mod_fcgid: get overlap result error
[Wed Nov 11 15:57:27 2009] [error] [client 192.168.21.21] Premature end of
script headers: foo.pl
I'd guess this is related to the shebang line processing, and that foo.pl isn't
getting started.
Is the path to perl correct in foo.pl (maybe it should be #!/perl/bin/perl)?
Do you need ScriptInterpreterSource registry to tie .pl files to the Perl
interpreter, ignoring the shebang line?
Re: [VOTE] release 2.3.3 as alpha
Gregg L. Smith wrote: Gregg L. Smith wrote: Sorry bout that, I always try first with VS6 SP6 SDK 2003R2 William A. Rowe Jr. wrote: Gregg L. Smith wrote: Generating Code... socket_util.c E:\build\httpd-2.3.3-alpha\srclib\apr\network_io\unix\socket_util.c(21) : error C2373: 'apr_socket_atreadeof' : redefinition; different type modifiers ./include\apr_network_io.h(362) : see declaration of 'apr_socket_atreadeof' We are missing a ton of information here; what VisualStudio and VC This on the surface seems misplaced. There is only one function in the offending file (socket_util.c), apr_status_t apr_socket_atreadeof(apr_socket_t *sock, int *atreadeof) should have been APR_DECLARE(apr_status_t) apr_socket_atreadof([...]) That function is only called from testsock.c, unless I manually include either testlib or testdll or both projects, testsock.c is never compiled and therefore this function is never called as well. Should this not then be moved out of libapr.dsp and into those two 'test' projects? No
mod_rewrite and mod_fcgid pass wrong fcgi request
Hi, i was friyng my brain the whole day trying to use a mod_rewrite simple rewrite to a php pathinfo running via mod_fcgid. http://domain.tld/path/info/use - http://domain.tld/index.php/path/info/use i trying so much posibilities, but when i take a strace to a php-fcgi application i found the surprise that php treats to open the file redirect:/index.php/path/info/use i cannot know if this behavior is a problem in mod_rewrite or mod_fcgid. someone can guide me with this? -- Felipe Alcacibar Buccioni Desarrollo y asesoria en sistemas y soluciones en tecnologías de la información y comunicación. -- i am using Gentoo Linux, mod_fcgid-2.3.4 (the source unpatched from the offical apache site) apache 2.2.11 rohan www # apache2 -V Server version: Apache/2.2.11 (Unix) Server built: Nov 10 2009 17:59:53 Server's Module Magic Number: 20051115:21 Server loaded: APR 1.3.8, APR-Util 1.3.9 Compiled using: APR 1.3.8, APR-Util 1.3.9 Architecture: 32-bit Server MPM: Worker threaded: yes (fixed thread count) forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR=server/mpm/worker -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT=/usr -D SUEXEC_BIN=/usr/sbin/suexec -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=/etc/apache2/mime.types -D SERVER_CONFIG_FILE=/etc/apache2/httpd.conf
Re: Obsolete modules in 2.3
Rich Bowen wrote: Client-side image maps have been part of HTML for more than a decade. Irrelevant for geographic maps - unless you define a different area for every pixel! Clientside maps only work with areas, which are generally associated with visual crap rather than anything functional like a point on a map. Altogether different class of application. -- Nick Kew
Re: svn commit: r835524 - in /httpd/mod_ftp/trunk: Makefile.apxs configure.apxs
traw...@apache.org wrote: Author: trawick Date: Thu Nov 12 20:14:51 2009 New Revision: 835524 URL: http://svn.apache.org/viewvc?rev=835524view=rev Log: pick up r834900 and r834923 from mod_fcgid Follow up the awk compatibility fix in r834729 by selecting the most suitable awk, following the AC_PROG_AWK order (gawk, mawk, nawk, awk). As with AC_PROG_AWK, AWK=foo overrides. After r834729 a working conf was generated on Solaris when using /usr/bin/awk, but only by some fluke of command-line processing (-v was sort-of ignored; see PR for discussion). Also, the LoadModule wasn't added in the right spot due to awk engine differences. Can't we take $AWK given in config_vars.mk/apr_rules.mk instead, using APXS?
Re: svn commit: r835524 - in /httpd/mod_ftp/trunk: Makefile.apxs configure.apxs
On Thu, Nov 12, 2009 at 6:52 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: traw...@apache.org wrote: Author: trawick Date: Thu Nov 12 20:14:51 2009 New Revision: 835524 URL: http://svn.apache.org/viewvc?rev=835524view=rev Log: pick up r834900 and r834923 from mod_fcgid Follow up the awk compatibility fix in r834729 by selecting the most suitable awk, following the AC_PROG_AWK order (gawk, mawk, nawk, awk). As with AC_PROG_AWK, AWK=foo overrides. After r834729 a working conf was generated on Solaris when using /usr/bin/awk, but only by some fluke of command-line processing (-v was sort-of ignored; see PR for discussion). Also, the LoadModule wasn't added in the right spot due to awk engine differences. Can't we take $AWK given in config_vars.mk/apr_rules.mk instead, using APXS? As of this commit, yes. As of the next commit, which works around missing tolower() in nawk on some levels of Solaris by preferring /usr/xpg4/bin/awk, no. I don't know levels of Solaris don't have tolower() in nawk. Perhaps it isn't a practical concern.
Re: svn commit: r835406 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_pm_main.c fcgid_proc_unix.c fcgid_proc_win.c fcgid_proctbl.h mod_fcgid.c
Hi, Jeff Thank you for the code style reference, I will follow this style next time :) Actually there are many space for extra info(like vhost), and we can just put this in the share memeory and output it through /server_status, but another issue is system security, I think we should not provide too much internal info to client(file full path, user id etc). So I now just output the info that nobody can get through ps -ef. But if it's no harm, please feel free to add more info to the share memory. Thanks -- From: Jeff Trawick traw...@gmail.com Sent: Friday, November 13, 2009 5:08 AM To: dev@httpd.apache.org Subject: Re: svn commit: r835406 - in /httpd/mod_fcgid/trunk/modules/fcgid: fcgid_pm_main.c fcgid_proc_unix.c fcgid_proc_win.c fcgid_proctbl.h mod_fcgid.c On Thu, Nov 12, 2009 at 10:05 AM, p...@apache.org wrote: Author: pqf Date: Thu Nov 12 15:05:08 2009 New Revision: 835406 URL: http://svn.apache.org/viewvc?rev=835406view=rev Log: Add fcgid extension to mod_status Hi Ryan, This looks extremely useful. Hopefully I can look at it more over the next few days. At first glance I think the process heading needs more information, such as the vhost or other attributes that distinguish the table from other tables for the same executable file, since otherwise it may be unexpected to see multiple tables for the same program, each with its own set of processes. For anyone that wants a quick look at the information, I've uploaded a sample page to http://people.apache.org/~trawick/mod_fcgid_status.html Thanks! BTW, I made some code formatting changes in r835540 to bring the new mod_status code closer to httpd project style (guidelines are at http://httpd.apache.org/dev/styleguide.html, examples for issues not covered there are throughout httpd).
