[jira] Created: (MODPYTHON-65) 3.2 working version will not install on Mac OS X (10.3.7)
3.2 working version will not install on Mac OS X (10.3.7) - Key: MODPYTHON-65 URL: http://issues.apache.org/jira/browse/MODPYTHON-65 Project: mod_python Type: Bug Components: core Versions: 3.2.0 Environment: Mac OS X (10.3.7) Reporter: Graham Dumpleton Something is wrong with configure or setup.py file. /usr/bin/python setup.py build running build running build_py running build_ext building 'mod_python_so' extension gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/mod_python.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/_apachemodule.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/connobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/filterobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/hlist.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/hlistobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/requestobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/serverobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/tableobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/util.o -L -lapr-0 -laprutil-0 -o build/lib.darwin-7.7.0-Power_Macintosh-2.3/mod_python_so.so ld: -L: directory name missing error: command 'gcc' failed with exit status 1 More later when I have a chance to work out what is wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-65) 3.2 working version will not install on Mac OS X (10.3.7)
[ http://issues.apache.org/jira/browse/MODPYTHON-65?page=comments#action_12316435 ] Graham Dumpleton commented on MODPYTHON-65: --- The problem here is that on Mac OS X, distutils compiles Python loadable modules in a way that expects all symbols to be resolvable at the time the module is created. That is, all symbols must be present in either the objects being linked into the module or in libraries which are explicitly linked with the module. In a scenario like mod_python where there will be undefined references to symbols which are only defined within the executable running the interpreter into which the module is loaded, this will fail. Previously this wasn't a problem because distutils wasn't used to create the module and instead the makefile use libtool to do it. One of the options to libtool was --silent. This option (at least I think so, it may be a different option), would underneath pass appropriate options to the linker for a platform to disable undefined symbols causing an error. Since distutils is now used, there is going to have to be platform specific hacks to add additional options to the link line when creating a module to add these platform specific options. This however is not as simple as defining extra_link_flags to the distutils extension object as they will only be placed at the end. These magic options tend to be positional dependent and need to be included at a specific spot early in the link line. The distutils package does not give you this level of control through its public APIs and thus a hack is required which delves into its private parts. If distutils changes, like it did from 2.2 to 2.3, this hack will break and no longer work. This problem may affect other platforms besides MacOSX as there are other platforms that also require specific options to ignore undefined symbols. Anyway, the hack required to get this to work for Mac OS X with Python 2.3 is as follows. If you know of a better way, by all means let me know. :-) Index: dist/setup.py.in === --- dist/setup.py.in(revision 220194) +++ dist/setup.py.in(working copy) @@ -85,7 +85,7 @@ returns apache lib directory apache_srcdir = getapache_srcdir() if apache_srcdir is None: -return +return getapxs_option(LIBDIR) else: return os.path.join(apache_srcdir, lib) @@ -153,6 +153,17 @@ scripts = [] data_files = [] +import string +from distutils import sysconfig + +if sys.platform == darwin: +sysconfig._config_vars[LDSHARED] = \ +string.replace(sysconfig.get_config_var(LDSHARED), \ + -bundle , -bundle -flat_namespace -undefined suppress ) +sysconfig._config_vars[BLDSHARED] = \ +string.replace(sysconfig.get_config_var(BLDSHARED), \ + -bundle , -bundle -flat_namespace -undefined suppress ) + setup(name=mod_python, version=VER, description=Apache/Python Integration, 3.2 working version will not install on Mac OS X (10.3.7) - Key: MODPYTHON-65 URL: http://issues.apache.org/jira/browse/MODPYTHON-65 Project: mod_python Type: Bug Components: core Versions: 3.2.0 Environment: Mac OS X (10.3.7) Reporter: Graham Dumpleton Something is wrong with configure or setup.py file. /usr/bin/python setup.py build running build running build_py running build_ext building 'mod_python_so' extension gcc -Wl,-F. -Wl,-F. -bundle -framework Python build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/mod_python.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/_apachemodule.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/connobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/filterobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/hlist.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/hlistobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/requestobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/serverobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/tableobject.o build/temp.darwin-7.7.0-Power_Macintosh-2.3/Users/grahamd/Workspaces/mod_python/src/util.o -L -lapr-0 -laprutil-0 -o build/lib.darwin-7.7.0-Power_Macintosh-2.3/mod_python_so.so ld: -L: directory name missing error: command 'gcc' failed with exit status 1 More later when I have a chance to work out what is wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the
[jira] Created: (MODPYTHON-66) install_dso target also tries to install Python code files.
install_dso target also tries to install Python code files. --- Key: MODPYTHON-66 URL: http://issues.apache.org/jira/browse/MODPYTHON-66 Project: mod_python Type: Bug Components: core Versions: 3.2.0 Reporter: Graham Dumpleton Priority: Minor After building mod_python it will output the message: Now su and make install (or, if you only want to perform a partial install, you can use make install_dso and make install_py_lib) The fact that there are separate targets for install_dso and install_py_lib gives the impression that install_dso will install only the Apache DSO module and that install_py_lib will install only the Python code files. This isn't the case. Although install_py_lib installs just the Python code files, the install_dso target installs both the DSO module and the Python code files. The install_dso target isn't actually much different to having run install when DSO is being used in that respect. As the ability to install just the DSO is useful, can there please be a separate target. Either this should be changed to do what it suggests it should, or a new target introduced. Ie., install_dso_and_just_the_dso. :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
ApacheCon BOF about Module Repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All who are at ApacheCon or are otherwise interested, I snatched a BOF slot tonight (Thursday the 21st) at 20:30 to discuss ideas for dealing with modules inside and outside the httpd distribution. This is so far just an idea... I named it TCAHMAN (pronounced Tikkaman) for The Comprehensive Apache Httpd Module Archive Network. The basic premise is to run: $ ./configure (...) --with-tcahman-shared=funkymod (...) and configure will contact the tcahman server (a.k.a. modules.apache.org), download the source code for funkymod and compile it into the server as an so. Or, it could access a locally downloaded module tarball in case the build box can't see the net: $ ./configure (...) --with-tcahman=/path/to/funkymod.tar.gz will find the tarball in the file system and compile it (statically, in this case) into the server. In a similar fashion, an installed httpd could come with a script that can download, build and install a module on the existing server. Perhaps an enhancement to APXS? For instance: $ apxs build --with-tcahman=funkymod On the server side of TCAHMAN, the main issue is Organization. I would like to model this after CPAN, but I have no idea how CPAN works in any case, what we'd need is a standard for what module code and its meta-data looks like: proper autoconf language to get it built, name and description for the search engine, which Apache version(s) the tarball works with, etc. The other side of the organization aspect is who gets to upload modules to this archive. Do we just open it up? Or do we impose any regulations on code quality or evilness? Who gets to enforce this (major time sink danger here)? What language would we use to make sure people don't attribute uploads of third-party code to us? Will modules.apache.org have a feedback engine where users can tell module developers their shit is broken? This or a similar construction would provide people who build httpd easier access to third-party modules. It would also provide a way out for modules we might not want in the core distribution anymore, but would still like to make available. It gives module authors visibility to users, to get their code in front of people who might want to run it. Let's bat this around tonight and see if this is something we want to do, and how we would go about it. Is there any beer left over from the Hackathon? S. - -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC33WCnjkrwtLH+RIRAl2eAJwITvvpbf297JUUVg2e1kPsWPiLpQCfTbCU 2y4cd6SZ+Rj83JO2IEY2y2E= =RwhU -END PGP SIGNATURE-
Problem in autoconf installation
Hello, I am trying to install a module for Apache2 in Tru64. While trying to install autoconf , I received the following Error ., ---checking for a BSD-compatible install... config/install-sh -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for expr... /sbin/expr checking for gm4... no checking for gnum4... no checking for m4... /usr/bin/m4 checking whether m4 supports frozen files... no configure: error: GNU M4 1.4 is required Even after installing GNU M4 1.4 , I get the same error ... Please help me out. Thanks in advance. --Rajesh R -Original Message- From: Sander Temme [mailto:[EMAIL PROTECTED] Sent: Thursday, July 21, 2005 3:44 PM To: dev@httpd.apache.org Subject: ApacheCon BOF about Module Repository -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All who are at ApacheCon or are otherwise interested, I snatched a BOF slot tonight (Thursday the 21st) at 20:30 to discuss ideas for dealing with modules inside and outside the httpd distribution. This is so far just an idea... I named it TCAHMAN (pronounced Tikkaman) for The Comprehensive Apache Httpd Module Archive Network. The basic premise is to run: $ ./configure (...) --with-tcahman-shared=funkymod (...) and configure will contact the tcahman server (a.k.a. modules.apache.org), download the source code for funkymod and compile it into the server as an so. Or, it could access a locally downloaded module tarball in case the build box can't see the net: $ ./configure (...) --with-tcahman=/path/to/funkymod.tar.gz will find the tarball in the file system and compile it (statically, in this case) into the server. In a similar fashion, an installed httpd could come with a script that can download, build and install a module on the existing server. Perhaps an enhancement to APXS? For instance: $ apxs build --with-tcahman=funkymod On the server side of TCAHMAN, the main issue is Organization. I would like to model this after CPAN, but I have no idea how CPAN works in any case, what we'd need is a standard for what module code and its meta-data looks like: proper autoconf language to get it built, name and description for the search engine, which Apache version(s) the tarball works with, etc. The other side of the organization aspect is who gets to upload modules to this archive. Do we just open it up? Or do we impose any regulations on code quality or evilness? Who gets to enforce this (major time sink danger here)? What language would we use to make sure people don't attribute uploads of third-party code to us? Will modules.apache.org have a feedback engine where users can tell module developers their shit is broken? This or a similar construction would provide people who build httpd easier access to third-party modules. It would also provide a way out for modules we might not want in the core distribution anymore, but would still like to make available. It gives module authors visibility to users, to get their code in front of people who might want to run it. Let's bat this around tonight and see if this is something we want to do, and how we would go about it. Is there any beer left over from the Hackathon? S. - -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC33WCnjkrwtLH+RIRAl2eAJwITvvpbf297JUUVg2e1kPsWPiLpQCfTbCU 2y4cd6SZ+Rj83JO2IEY2y2E= =RwhU -END PGP SIGNATURE-
Re: svn commit: r219936 - in /httpd/httpd/trunk/modules/aaa: mod_authz_dbm.c mod_authz_groupfile.c mod_authz_user.c
On Wed, Jul 20, 2005 at 04:23:38PM -, [EMAIL PROTECTED] wrote:
-if (!strcmp(w, file-group)) {
+if (!cmpstri(w, file-group)) {
Um, what's this? Shouldn't that be strcasecmp? -- justin
Re: Initial mod_smtpd code.
On Wed, 20 Jul 2005, Paul A Houle wrote: Jem Berkes wrote: I could also start work on a mod_smtpd_dnsbl if the mentors feel that is worthwhile? This would look up a connecting IP address against a blacklist and return a descriptive string to mod_smtpd if the client should be rejected with an error: 550 5.7.1 Email rejected because 127.0.0.2 is listed by sbl-xbl.spamhaus.org I'd also like to include support for RHSBL, a newer type of listing by domain names from the envelope sender address. That's used by a growing number of projects. Overall blacklists aren't that effective and cause a lot of false positives. The issue is about developing enabling technology. Jem's proposals are for a couple of modules we'd like to see developed. A spamassassin filter is also on the wishlist, but availability of solutions that avoid the formidable spamassassin overhead seem to me a Good Thing. Perhaps the answer is for Jem's modules to have options either to reject outright or to accept but increment a score that can then be aggregated with results from other modules. -- Nick Kew
[Fwd: [PATCH] 404 does not delete cached entries using mod_disk_cache]
Forwarding for Rüdiger, since he's having some problems posting. Sander Original Message Subject: [PATCH] 404 does not delete cached entries using mod_disk_cache Date: Thu, 21 Jul 2005 14:52:19 +0200 From: Plüm, Rüdiger, VIS [EMAIL PROTECTED] To: [EMAIL PROTECTED] After having a discussion with various people (Sander, Justin, Paul) at the ApacheCon I submit a new version of my 404 does not delete cached entries using mod_disk_cache: Some comments: 1. In the case that there is an Apache generated error message the content filters get removed. This problem is now solved by adding a protocol filter (CACHE_REMOVE_URL) in the quick handler each time we add the cache save filter. If the cache save filter caches the response from the backend it just removes this filter from the chain. As the request CACHE_REMOVE_URL is running on a request that might be different fromi the one where the cache entry should be flushed, the cache request rec is taken from the filter context where it has been saved during insertation. 2. I adjusted the cache provider API for remove_url as I needed to have a pool and (in case of mod_disk_cache) the file name present at remove_url. Thus the prototype for remove url does now look like the following: int (*remove_url) (cache_handle_t *h, apr_pool_t *p); Comments / thoughts? Regards Rüdiger new_404_patch_trunk.diff Description: Binary data
Re: Dispatching MPM
On Mon, 18 Jul 2005, Michal Kosek wrote: Implementation issues Dispatcher It would be best to make dispatcher single-threaded, I suppose that creating separate thread for each connection would take much more resources. OTOH it may cause some problems. One I am currently aware of is mod_ssl, which AFAIK doesn't currently have non-blocking API. Would it be difficult to create such API? I want dispatcher to be as simple as possible, and make workers do all the work (filters, handlers, etc.). Of course, as dispatcher must read Host header, it must use connection filters. This headers is needed, because dispatcher has to decide to which worker a connection should be redirected. I think that it would be best if it didn't do full header parsing, but just look for virtual host name. There are two ways of dispatching connection: - passing a socket descriptor (along with data that were already read) to the appropriate worker, - acting as a proxy, redirecting data to the appropriate worker. I understand you favour the proxy solution. That seems to mean that the elapsed time from the dispatcher accepting a request to being finished with it is the entire request duration, including the overhead of your architecture. Isn't that quite expensive, in terms of requiring a whole bunch of dispatcher processes? -- Nick Kew
Re: svn commit: r219936 - in /httpd/httpd/trunk/modules/aaa: mod_authz_dbm.c mod_authz_groupfile.c mod_authz_user.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Justin Erenkrantz wrote:
On Wed, Jul 20, 2005 at 04:23:38PM -, [EMAIL PROTECTED] wrote:
-if (!strcmp(w, file-group)) {
+if (!cmpstri(w, file-group)) {
Um, what's this? Shouldn't that be strcasecmp? -- justin
Sorry. This is actually my very first code patch in all the years I've
been working with Apache. Picking a nit. Will fix.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC382sXP03+sx4yJMRApIBAJ9eBq94XXJ8x1Nw0HC11ZsTYaoRoQCfR+kg
K6HVHeomYwlJOjBkxSnIBq0=
=IHdT
-END PGP SIGNATURE-
apr_pool_cleanup_kill() -- thread-safety?
I stumbled across this issue, chasing a bug from a module that gets
into an infinite loop.
It looked to me that the following section of code within
apr_pool_cleanup_kill is not thread-safe.
But I'm not familiar with the internals/api assumptions, so please
let me know if this is indeed a bug with the apr_pools implementation
[as opposed to a mis-use of apr_pools within the module.]
Here is the relevent section in apr_pools.c that seemed
to me to be unsafe.
APR_DECLARE(void) apr_pool_cleanup_kill(apr_pool_t *p, const void *data,
apr_status_t (*cleanup_fn)(void *))
{
cleanup_t *c, **lastp;
#if APR_POOL_DEBUG
apr_pool_check_integrity(p);
#endif /* APR_POOL_DEBUG */
if (p == NULL)
return;
c = p-cleanups;
lastp = p-cleanups;
while (c) {
if (c-data == data c-plain_cleanup_fn == cleanup_fn) {
*lastp = c-next;
break;
}
lastp = c-next;
c = c-next;
}
}
Two threads can concurrently access/update the linked list, causing
[in my case] an infinite loop to occur.
Here is the stack trace for a process which got into this
state:
#0 apr_pool_cleanup_kill (p=0x80d4f90, data=0x8334a10,
cleanup_fn=0x4021b488 socket_cleanup) at apr_pools.c:1904
#1 0x40222bea in apr_pool_cleanup_run (p=0x80d4f90, data=0x8334a10,
cleanup_fn=0x4021b488 socket_cleanup) at apr_pools.c:1941
#2 0x4021b734 in apr_socket_close (thesocket=0x8334a10) at sockets.c:125
#3 0x402baee3 in jk2_channel_apr_close (env=0x8237618, ch=0x8176450,
endpoint=0x82e8ee0)
at ../../common/jk_channel_apr_socket.c:363
#4 0x402c8ab6 in jk2_close_endpoint (env=0x8237618, ae=0x82e8ee0) at
../../common/jk_worker_ajp13.c:250
#5 0x402c91d0 in jk2_worker_ajp13_forwardStream (env=0x8237618,
worker=0x817a470, s=0x830bec8, e=0x82e8ee0)
at ../../common/jk_worker_ajp13.c:549
#6 0x402c9458 in jk2_worker_ajp13_service1 (env=0x8237618,
w=0x817a470, s=0x830bec8, e=0x82e8ee0)
at ../../common/jk_worker_ajp13.c:642
#7 0x402c98f1 in jk2_worker_ajp13_service (env=0x8237618,
w=0x817a470, s=0x830bec8) at ../../common/jk_worker_ajp13.c:814
#8 0x402d22a6 in jk2_handler (r=0x41232568) at
../../server/apache2/mod_jk2.c:733
#9 0x08092bfe in ap_run_handler (r=0x41232568) at config.c:151
#10 0x08093119 in ap_invoke_handler (r=0x41232568) at config.c:363
#11 0x08083913 in ap_process_request (r=0x41232568) at http_request.c:246
#12 0x0807f924 in ap_process_http_connection (c=0x82bce88) at
http_core.c:250
#13 0x0809bf96 in ap_run_process_connection (c=0x82bce88) at
connection.c:42
#14 0x0808fecf in process_socket (p=0x82bcd60, sock=0x82bcd98,
my_child_num=2, my_thread_num=8, bucket_alloc=0x41236540)
at worker.c:520
#15 0x080904a2 in worker_thread (thd=0x8152f20, dummy=0x41202448) at
worker.c:834
#16 0x4021d660 in dummy_worker (opaque=0x8152f20) at thread.c:88
#17 0x4022efaf in pthread_start_thread () from /lib/i686/libpthread.so.0
(gdb)
The apache version used in this process was apache-2.0.52, but I see
the same code in 2.0.54 as well.
Other information which might be useful:
Server version: httpd/1.0.0
Server built: Nov 17 2004 12:18:59
Server's Module Magic Number: 20020903:9
Architecture: 32-bit
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 HTTPD_ROOT=/opt/usr/apps/scw
-D SUEXEC_BIN=/opt/usr/apps/scw/bin/suexec
-D DEFAULT_SCOREBOARD=logs/apache_runtime_status
-D DEFAULT_ERRORLOG=logs/error_log
-D AP_TYPES_CONFIG_FILE=conf/mime.types
-D SERVER_CONFIG_FILE=conf/httpd.conf
__
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
