Re: Apache2 / mod_perl1 confusion
Gavin Carr wrote: On Fri, Jan 21, 2005 at 09:26:53AM -0500, Geoffrey Young wrote: I'm trying to test a C module against both apache2 and apache1. apache1 is working beautifully, but when I attempt to reconfigure for apache2 (stock FC1), A::T (1.20) keeps complaining about finding mod_perl 1. I'm doing: ./TEST -clean ./TEST -apxs /usr/sbin/apxs -conf when I run tests against both apache 1 and apache 2 I generally 'make realclean' and then re- perl Makefile.PL -apxs... and it works just fine. if you look in t/TEST you'll probably see your old -apxs path in there. well, that is, if you specified -apxs when building your Makefile :) Since this is a C module I'm actually just using a static TEST like this: #!/usr/bin/perl use strict; use warnings FATAL = 'all'; use Apache::TestRunPerl; Apache::TestRunPerl-new-run(@ARGV); since it's just a C module and you don't need mod_perl you should change that Apache::TestRunPerl to just Apache::TestRun. that should make A-T use the inherited mod_perl from httpd.conf instead of hunting around for it. straight out of one of the A::T tutorials. you should check out the code from the tutorial I gave at ApacheCon. the code is here http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2004/test-driven-development-code.tar.gz and the tutorial slides are here http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2004/test-driven-development.pdf pay particular attention to mod_example_ipc-install in the code tarball. basically, put your C module in c-modules following the pattern you'll see there (filenames and directory names and declarations are important). then let Perl manage t/TEST and the Makefile for you using makefile. No change with APACHE_TEST_NO_STICKY_PREFERENCES=1, and I don't have a ~/.apache-test at all. Nothing actually ends up in t/conf after the -conf run either - it looks like it's just bailing out. hmm, that's odd. Any further suggestions of where to look? Might be perl debugger time ... I would start with copying the workflow I outline in the tarball I mentioned above. it's a bit different than what you're doing now, so it may feel strange, but give it a whirl and see if it works. then you can decide if you like it or not :) HTH --Geoff
[PATCH] #2 versioned libtool.m4 files for FreeBSD
On Sun, 16 Jan 2005 at 10:06:16 -0800, Justin Erenkrantz wrote:
This busts on Darwin as it uses libtool.m4 even though libtool is glibtool.
And, libtoolize is usually going to be in the same location as libtool, so why
the need for the extra PrintPath call?
I think the right way to do it is to first check for libtool.m4, then check
for 'echo $libtoolize | sed -e s/ize//g'.m4 in the aclocal dir. -- justin
Sorry for not reacting for so long. Here's take #2 in the attempt to
find a conservative solution for the problem that FreeBSD may have
several libtoolXX and libtool*.m4 files installed in parallel.
Justin or Paul, can you please check it on Darwin? On FreeBSD-4.10, it
seems to work ;-)
Martin
BTW: How does Darwin manage to have several libtools in parallel when
it does not rename their libtool.m4 files?
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Index: buildconf
===
--- buildconf (Revision 126171)
+++ buildconf (Arbeitskopie)
@@ -46,7 +46,18 @@
ltfile=`pwd`/libtool.m4
else
ltpath=`dirname $libtoolize`
- ltfile=${LIBTOOL_M4-`cd $ltpath/../share/aclocal ; pwd`/libtool.m4}
+ ltpath=`cd $ltpath/../share/aclocal ; pwd`
+ # Search for a libtool.m4 file. On FreeBSD and Darwin, several versions
+ # of libtool can coexist, by renaming the command, e.g., libtoolize15 (for
V1.5)
+ # but only on FreeBSD the corresponding libtool.m4 files in ../aclocal/ are
+ # also renamed libtool15.m4 . Here we try the normal name(s) first, and
+ # then fall back to searching for a renamed libtool.m4 file.
+ for ltfile in ${LIBTOOL_M4} $ltpath/libtool.m4 $ltpath/`basename
$libtoolize | sed -e s/ize//g'`.m4
+ do
+ if [ -f $ltfile ]; then
+ break
+ fi
+ done
fi
if [ ! -f $ltfile ]; then
Re: [PATCH] #2 versioned libtool.m4 files for FreeBSD
Oops - wrong dev@ -- please ignore. Martin -- [EMAIL PROTECTED] | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
Re: [PATCH] Synchronize requests_this_child
Paul Querna wrote: Attached ia a patch for the Worker MPM that uses APR Atomics to change the value of requests_this_child. I changed it around to count *up*, instead of counting down... So I would like someone else to look at it before I commit it. -0.5 What's the point? This slows down the server for no good purpose. Atomic operations are more expensive than their non-atomic counterparts. Plus, switching from decrement to increment makes the loop test slightly more complex. Yes, we will loose a few updates now and then on SMP systems. All this variable does is cause child processes to exit after a while, mostly as a defense mechanism against memory leaks. Mostly I see it set to 0 or something like 1. I have yet to hear a complaint from a user that in the latter case a child process actually handled 10003 connections before exiting. Greg
Re: Proposal: R-T-C and packaging files
On Jan 23, 2005, at 9:28 AM, Graham Leggett wrote: Hi all, There has been an ongoing problem with httpd and system package build scripts. Over time, changes have been backported to the build system (autoconf, etc) which breaks packaging scripts and files such as the RPM spec file. The packaging files are then fixed, but the backport sits in the STATUS file without enough votes to move it forward, and eventually a release is made with broken packaging. What I propose is that changes to packaging files (such as build/rpm/httpd.spec.in, build/pkg/buildpkg.sh, etc) should be CTR, just as documentation files are. This will not apply if other files (source code for example) are involved in the change. ++1 !
mod include behaviour
Can somebody confirm this is a deliberate feature? If I write: !--#set var=crumbs value=a href='/'Home/a gt; -- !--#echo encoding='none' var='crumbs' -- The 'gt;' gets sent to the client as a literal '', which means that I need to write: !--#set var=crumbs value=a href='/'Home/a amp;gt; -- The reason for this seems to be the '1' as the final call to ap_ssi_get_tag_and_value in handle_set in mod_include.c This isn't what I expect from the docs and it seems an extremely strange thing for a _server_ to be doing. At the least it should be documented (and maybe made optional?) John
Error linking to ApacheCore.lib in win32
My apologies because this is probably not the correct list, but I'm
looking for someone intimate with C and the httpd internals/exports.
I didn't figured I'd get much of an anwser from users@ and this isn't
exactly a mod_* question either.
--
I'm trying to compile a whole slew of things for a new install on my
laptop for dev, including libxml2, libxslt, mod_perl, and AxKit.
Everything is done and passed all the tests with the exception of AxKit.
What does this have to do with Apache you ask? Well, I'm getting errors
linking against ApacheCore.lib in my 1.3.33 Apache install. This is the
packages binary install from apache.org.
The error is:
axconfig.obj : error LNK2001: unresolved external symbol _ap_invoke_handler
blib\arch\auto\AxKit\AxKit.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code
'0x460'
Stop.
Now, the AxKit Makefile has the full path to ApacheCore.lib in it;
without spaces. Removing that entry produces more errors, so it's
definately getting linked to.
The relevant portion in AxKits' axconfig.c is:
/* - axconfig.c - */
static int axkit_handler(request_rec *r)
{
int retval;
SV * handler_sv;
SV * cfg;
SV * debuglevel;
SV * errorlevel;
if (S_ISDIR(r-finfo.st_mode)) {
axkit_dir_config * cfg = (axkit_dir_config
*)ap_get_module_config(r-per_dir_config, XS_AxKit);
if (!cfg || cfg-handle_dirs != 1) {
return DECLINED;
}
}
handler_sv = newSVpv(AxKit::fast_handler, 0);
cfg = perl_get_sv(AxKit::Cfg, FALSE);
debuglevel = perl_get_sv(AxKit::DebugLevel, FALSE);
errorlevel = perl_get_sv(Error::Debug, FALSE);
ENTER;
save_item(cfg);
save_item(debuglevel);
save_item(errorlevel);
retval = perl_call_handler(handler_sv, (request_rec *)r, Nullav);
LEAVE;
SvREFCNT_dec(handler_sv);
if (retval == DECLINED) {
r-handler = default-handler;
return ap_invoke_handler(r);
}
return retval;
}
/* - axconfig.c - */
I've also done a dumpbin on ApacheCore.lib and ApacheCore.dll to confirm
that ap_invoke_handler is indeed exported.
The Microsoft KB has a million and one reasons that cause LNK1120 error,
and I don't know a damn thing about C.
Any C guru Apache internals god out there have any ideas?
Thanks,
-=Chris
Re: Proposal: R-T-C and packaging files
At 08:28 AM 1/23/2005, Graham Leggett wrote: The packaging files are then fixed, but the backport sits in the STATUS file without enough votes to move it forward, and eventually a release is made with broken packaging. I think we discussed this at ApacheCon - an .rpm spec file, .pkg description, or whatever should be considered a platform issue - left to the platform maintainer and a handful of helpers to maintain under lazy concensus. Propose your fix, and let the few who follow the issue pipe up if they like. For a stable branch though - more often such changes should just be -vetoed- instead of worked-around. Packaging changes would seem to signal breakage, not a reason for a workaround. What I propose is that changes to packaging files (such as build/rpm/httpd.spec.in, build/pkg/buildpkg.sh, etc) should be CTR, just as documentation files are. This will not apply if other files (source code for example) are involved in the change. -1 not CTR. Lazy consensus. Propose, give 3 - 5 days (what ever your schedule best provides) and then commit. If folks object they will speak up - if not - then you aren't hampered. And documentation is (more often than not) R-T-C, at least in terms of translations, etc. Brad and I have operated that way for years. Bill
Re: Proposal: R-T-C and packaging files
William A. Rowe, Jr. said: For a stable branch though - more often such changes should just be -vetoed- instead of worked-around. Packaging changes would seem to signal breakage, not a reason for a workaround. -1 not CTR. Lazy consensus. Propose, give 3 - 5 days (what ever your schedule best provides) and then commit. If folks object they will speak up - if not - then you aren't hampered. Seems reasonable. +1. Regards, Graham --
