Steve Baldwin wrote:
I've got Apache2 installed and as far as I can tell, it is functional.We need to explicitly set $ENV{PATH} to be able to start a process under -T (see perlsec). We could hardcode the path of the value, but that would be different for each platform. What the normal value of PATH on your system? Is this something standard that other cygwin users can rely on?
I'm trying to build mod-perl from source (as I couldn't find any
binaries for cygwin). When I initially ran the command :
perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
I got errors telling me it couldn't find "cygdb-3.1.dll", which I
eventually tracked down to Apache::TextConfig::open_cmd. I commented
out the line :
local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };
and the errors went away (it was clearing $ENV{PATH} which I think was
causing the error).
However, when I run 'make', I get the following ...[mod_perl-1.99_08]$ make cd "src/modules/perl" && make -f Makefile.modperl make[1]: Entering directory `/cygdrive/d/Downloads/mod_perl-1.99_08/src/modules/perl' gcc -I/cygdrive/d/Downloads/mod_perl-1.99_08/src/modules/perl -I/cygdrive/d/Downloads/mod_perl-1.99_08/xs -I/usr/local/apache2/include -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE -DMOD_PERL -O2 \ -c mod_perl.c && mv mod_perl.o mod_perl.lo mod_perl.c: In function `modperl_shutdown': mod_perl.c:10: `my_perl' undeclared (first use in this function) mod_perl.c:10: (Each undeclared identifier is reported only once mod_perl.c:10: for each function it appears in.) mod_perl.c: In function `modperl_hook_post_config': mod_perl.c:498: `my_perl' undeclared (first use in this function) mod_perl.c: In function `modperl_response_handler_cgi': mod_perl.c:771: `my_perl' undeclared (first use in this function) make[1]: *** [mod_perl.lo] Error 1 make[1]: Leaving directory `/cygdrive/d/Downloads/mod_perl-1.99_08/src/modules/perl' make: *** [modperl_lib] Error 2
The key is:
[mod_perl-1.99_08]$ perl -V
[...]
You don't have threads enabled, but you do have multiplicity enabled. I thought that this problem could be workarounded with this:usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define
Index: src/modules/perl/modperl_perl_includes.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl_includes.h,v
retrieving revision 1.17
diff -u -r1.17 modperl_perl_includes.h
--- src/modules/perl/modperl_perl_includes.h 25 Nov 2002 01:31:00 -0000 1.17
+++ src/modules/perl/modperl_perl_includes.h 17 Feb 2003 04:14:48 -0000
@@ -42,6 +42,19 @@
# endif
#endif
+/* If perl was compiled with MULTIPLICITY and/or
+ * PERL_IMPLICIT_CONTEXT, but no USE_ITHREADS, for mod_perl 2.0 it's
+ * the same as no multiplicity at all. This is to simplify the #ifdef
+ * logic of handling the perl context switching */
+#ifndef USE_ITHREADS
+# ifdef PERL_IMPLICIT_CONTEXT
+# undef PERL_IMPLICIT_CONTEXT
+# endif
+# ifdef MULTIPLICITY
+# undef MULTIPLICITY
+# endif
+#endif
+
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
but unfortunately this won't work, as certain PL_ variables aren't defined without defined(MULTIPLICITY), while they are defined in the perl core library. I suppose there are many other problems with this approach.
We can take two approaches, patch all the places in the code where perl context is set explicitly to use #ifdef MULTIPLICITY, rather than #ifdef USE_THREADS. Or we can refuse to build mod_perl if MULTIPLICITY is enabled without the threads. Of course the first solution is more favorable for users.
But may I ask why do you have MULTIPLICITY enabled? Is it required for cygwin perl (fork emulation?)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
