Re: mod_perl-1.31 compilation with perl 5.14.1 fails
On Tue, Jul 12, 2011 at 12:36 PM, Perrin Harkins per...@elem.com wrote: On Mon, Jul 11, 2011 at 11:39 PM, Fred Moyer f...@redhotpenguin.com wrote: Looks like a patch for this issue was posted. Greg, do you want to try out this patch and report back? https://rt.cpan.org/Public/Bug/Display.html?id=64999#txn-954785 This patch fixed it for me on CentOS. Thanks for testing it, patch applied r1151597. And a huge thanks to Todd Wade for submitting the patch!
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
On Mon, Jul 11, 2011 at 11:39 PM, Fred Moyer f...@redhotpenguin.com wrote: Looks like a patch for this issue was posted. Greg, do you want to try out this patch and report back? https://rt.cpan.org/Public/Bug/Display.html?id=64999#txn-954785 This patch fixed it for me on CentOS. - Perrin
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
Looks like a patch for this issue was posted. Greg, do you want to try out this patch and report back? https://rt.cpan.org/Public/Bug/Display.html?id=64999#txn-954785 On Mon, Jul 4, 2011 at 10:20 AM, Fred Moyer f...@redhotpenguin.com wrote: On Mon, Jun 27, 2011 at 4:54 PM, Gregory Coleman gregory.cole...@cbsinteractive.com wrote: hello - am getting compilation errors in building older mod_perl with newer perl. Things worked as of 5.12.X, but alas, not with today's 5.14.1 ... Any witnesses/experiences/thoughts on this? For what it is worth, I successfully compiled mod_perl 1.31 with apache 1.3.42 and perl 5.14.1 on my snow leopard based platform. I used the EVERYTHING=1 option with 'perl Makefile.PL'.
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
According to Fred Moyer f...@redhotpenguin.com on Tue, 06/28/11 at 16:50: Some in this thread : http://www.gossamer-threads.com/lists/modperl/modperl/103167 The problem here didn't appear to be 5.14 compatibility, more an issue of an inexperienced user trying to setup the latest version of httpd/perl/mod_perl. No specific 5.14 incompatibilities were identified. I am a bit surprised by your summary of my problem. I have been a user of FreeBSD since 1996 and have found the FreeBSD ports system to be an excellent resource and advantage to the UNIX world. The way I insure my systems are relatively free of security risks is to keep my operating system up-to-date and my applications rebuilt when security issues are disseminated. It is always a good idea to use the tested and packaged versions of mod_perl/httpd that come with your operating system if you are looking to deploy a production application and don't have much experience with compiling from source. Note that I most certainly am using/building the apache2 and mod_perl2 that come with my operating system. In fact, I would be had pressed to consider doing otherwise. While I am not by any measure an expert on mod_perl (1 or 2), a recent well respected application required me to build apache2 and mod_perl2 in order to run that Perl application. And when I say build here, I mean build from source using the FreeBSD ports system. Prior to my June 9th upgrade of both my operating system and all my ports (all the user-land applications), I had been running apache2 (2.1.7) along with mod_perl2 (2.0.4) successfully for months. Note that all these ports were built from up-to-date source per the excellent FreeBSD ports system meta-structure, ditto the FreeBSD 8.2-STABLE operating system. I had followed the README that came with this Perl web application (which was not in the ports tree, but came as a tar file) to configure apache2 and mod_perl2. Everything was fine and ran smoothly. Then I did the June 9th upgrade, and after the build of almost all my ports was complete, I attempted to launch apache2. This failed. :-( Since I got a strange error from apachectl(8) I immediately suspected the newer versions of either apache2 (2.1.9) or mod_perl2 (2.0.5). I had also upgraded to Perl 5.14 from the prior 5.12.3 version I had been running up until June 9th, but I didn't suspect Perl 5.14 until later. When I asked the developers of the Perl application about this error, they were clueless. I was led to suspect something in their code base after running down several suggestions both local and from various mailing lists. When the dust settled, and since I have neither the time nor the expertise to debug the issue with any of these large packages (apache2, mod_perl2, Perl, this Perl web application), I made the reluctant decision to completely redo my June 9th upgrade but this time moving back to Perl 5.12.3 to see if that one change would help. As I have reported to those venues attempting to assist me, this upgrade was successful. Note that the only thing that changed in this upgrade was the version of Perl. The apache2, mod_perl2 and the Perl web application were identical to the June 9th upgrade. In fact, not one thing had changed with the Perl web application since March 2011. The way the FreeBSD ports system operates, one can use pre-built binaries, or one can build ports from source, or a mixture of both. I always (re-)build from source (including the operating system), even when this may seen unnecessary. I do this infrequently enough that the burden is acceptable, but I do it often enough to ensure my system has no known security risks. However, I did not plan to do two ground-up rebuilds within a two week period! This experience (and some issues I had with one other FreeBSD port) made me suspect Perl 5.14 (or perhaps, the side effects in other code bases that use Perl caused by changes found in Perl 5.14). It may take several months for all the affected software packages to migrate to being compatible with Perl 5.14 but I am happy to remain at Perl 5.12.3 for the foreseeable future since everything works. Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
On Wed, Jun 29, 2011 at 5:39 AM, William Bulley w...@umich.edu wrote: According to Fred Moyer f...@redhotpenguin.com on Tue, 06/28/11 at 16:50: Some in this thread : http://www.gossamer-threads.com/lists/modperl/modperl/103167 The problem here didn't appear to be 5.14 compatibility, more an issue of an inexperienced user trying to setup the latest version of httpd/perl/mod_perl. No specific 5.14 incompatibilities were identified. I am a bit surprised by your summary of my problem. I have been a user of FreeBSD since 1996 and have found the FreeBSD ports system to be an excellent resource and advantage to the UNIX world. My apologizes, I didn't mean to imply that you were inexperienced overall, but it seemed like you didn't have much experience with setting up mod_perl apps, specifically with startup.pl. Or whomever built the app you were installing didn't put the startup.pl program together like it is recommended in the docs. It looked like we kind of lost the 2.0.6-dev/5.14 aspect of that thread too, and after running 5.14 with 2.0.6 for a month or so now, I haven't run into any compatibility issues there.
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
According to Fred Moyer f...@redhotpenguin.com on Wed, 06/29/11 at 14:04: My apologizes, I didn't mean to imply that you were inexperienced overall, but it seemed like you didn't have much experience with setting up mod_perl apps, specifically with startup.pl. Or whomever built the app you were installing didn't put the startup.pl program together like it is recommended in the docs. No need to apologize. I just wanted to clarify for any who joined in the thread late. The application in question has no startup.pl file. It is a Mason based web application and starts with an index.html file that has embedded Perl code. I have only been working with this application for a few months, and due to its large size (92 MB deployed), I have yet to understand all aspects of it. Not only am I new to mod_perl2, I am also new to Mason, sigh... :-( It looked like we kind of lost the 2.0.6-dev/5.14 aspect of that thread too, and after running 5.14 with 2.0.6 for a month or so now, I haven't run into any compatibility issues there. I was advised (by you?) to try mod_perl2 (2.0.6) just to see if 2.0.5 was at fault. I did and it wasn't. I am leaning toward some Perl 5.14 issue that exists within this large Perl web application. I have asked the developers there to try running their application under Perl 5.14 and have yet to hear any feedback on that suggestion. YMMV. BTW, several other Perl based web applications I have written are built on CGI::Application and do have what you call a startup.pl file although those (short) files are rarely, if ever, called startup.pl. Maybe I need to read more about the mod_perl2 experience. :-) Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
Le lundi 27 juin 2011 à 16:54 -0700, Gregory Coleman a écrit : hello - am getting compilation errors in building older mod_perl with newer perl. Things worked as of 5.12.X, but alas, not with today's 5.14.1 Any witnesses/experiences/thoughts on this? Some in this thread : http://www.gossamer-threads.com/lists/modperl/modperl/103167 -- Vincent Veyron http://marica.fr/ Logiciel de gestion des sinistres et des contentieux pour le service juridique
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
On Tuesday, June 28, 2011 11:57:47 Vincent Veyron wrote: Le lundi 27 juin 2011 à 16:54 -0700, Gregory Coleman a écrit : hello - am getting compilation errors in building older mod_perl with newer perl. Things worked as of 5.12.X, but alas, not with today's 5.14.1 Any witnesses/experiences/thoughts on this? Some in this thread : http://www.gossamer-threads.com/lists/modperl/modperl/103167 No. The point is mp1 has reached end of life as of Feb 2010: http://www.gossamer-threads.com/lists/modperl/modperl/101027 There were a few incompatible code changes in perl 5.14, particularly with SvGP and SvCV used in lvalue context, see also https://rt.cpan.org/Ticket/Display.html?id=64999 I doubt that any one of the current dev team will incorporate these changes into mp1. Though, if someone provides patches I think there are good chances for them to get applied especially if that someone wants to take care of mp1 in the future and thus become a committer. Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
On Tue, Jun 28, 2011 at 2:57 AM, Vincent Veyron vv.li...@wanadoo.fr wrote: Le lundi 27 juin 2011 à 16:54 -0700, Gregory Coleman a écrit : hello - am getting compilation errors in building older mod_perl with newer perl. Things worked as of 5.12.X, but alas, not with today's 5.14.1 Any witnesses/experiences/thoughts on this? Some in this thread : http://www.gossamer-threads.com/lists/modperl/modperl/103167 The problem here didn't appear to be 5.14 compatibility, more an issue of an inexperienced user trying to setup the latest version of httpd/perl/mod_perl. No specific 5.14 incompatibilities were identified. It is always a good idea to use the tested and packaged versions of mod_perl/httpd that come with your operating system if you are looking to deploy a production application and don't have much experience with compiling from source.
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
2011/6/28 Torsten Förtsch torsten.foert...@gmx.net: On Tuesday, June 28, 2011 11:57:47 Vincent Veyron wrote: Le lundi 27 juin 2011 à 16:54 -0700, Gregory Coleman a écrit : hello - am getting compilation errors in building older mod_perl with newer perl. Things worked as of 5.12.X, but alas, not with today's 5.14.1 Any witnesses/experiences/thoughts on this? Some in this thread : http://www.gossamer-threads.com/lists/modperl/modperl/103167 No. The point is mp1 has reached end of life as of Feb 2010: http://www.gossamer-threads.com/lists/modperl/modperl/101027 There were a few incompatible code changes in perl 5.14, particularly with SvGP and SvCV used in lvalue context, see also https://rt.cpan.org/Ticket/Display.html?id=64999 I doubt that any one of the current dev team will incorporate these changes into mp1. Though, if someone provides patches I think there are good chances for them to get applied especially if that someone wants to take care of mp1 in the future and thus become a committer. I took a look through Symbol.xs and it didn't look like there were too many places those macros had to be updated. And I actually understood some of the implementations so my XS appears to be getting better. But like you said, getting the tuits to make this happen and support it will be tough with the current mp2 needs.
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
On 06/28/2011 05:40 AM, Torsten Förtsch wrote:
On Tuesday, June 28, 2011 11:57:47 Vincent Veyron wrote:
Le lundi 27 juin 2011 à 16:54 -0700, Gregory Coleman a écrit :
hello - am getting compilation errors in building older mod_perl
with newer perl. Things worked as of 5.12.X, but alas, not with
today's 5.14.1
Any witnesses/experiences/thoughts on this?
Some in this thread :
http://www.gossamer-threads.com/lists/modperl/modperl/103167
No. The point is mp1 has reached end of life as of Feb 2010:
http://www.gossamer-threads.com/lists/modperl/modperl/101027
Is apache httpd 1.3 that reached EOL, not mp1. As far as I known the
lasts comments on the topic was on February this year:
http://www.gossamer-threads.com/lists/modperl/dev/102712
There were a few incompatible code changes in perl 5.14, particularly
with SvGP and SvCV used in lvalue context, see also
https://rt.cpan.org/Ticket/Display.html?id=64999
I doubt that any one of the current dev team will incorporate these
changes into mp1. Though, if someone provides patches I think there are
good chances for them to get applied especially if that someone wants to
take care of mp1 in the future and thus become a committer.
From the annotated thread I understand that Phillip M. Gollucci was
planning a final mp v1.32 but without given ETA.
I use both apache 1.3.x and mp1 for our in-house projects so I'm
collecting patches to keep both sane with recent distros.
Attached the diff on the subject from *our* repo, so some line offsets
may be misaligned.
Regards.
Salvador Ortiz.
Index: src/modules/perl/mod_perl.c
===
--- src/modules/perl/mod_perl.c (revision 2779)
+++ src/modules/perl/mod_perl.c (revision 2861)
@@ -848,7 +848,7 @@
/* *CORE::GLOBAL::exit = \Apache::exit */
if(gv_stashpv(CORE::GLOBAL, FALSE)) {
GV *exitgp = gv_fetchpv(CORE::GLOBAL::exit, TRUE, SVt_PVCV);
- GvCV(exitgp) = perl_get_cv(Apache::exit, TRUE);
+ GvCV_set(exitgp, perl_get_cv(Apache::exit, TRUE));
GvIMPORTED_CV_on(exitgp);
}
Index: src/modules/perl/mod_perl.h
===
--- src/modules/perl/mod_perl.h (revision 2779)
+++ src/modules/perl/mod_perl.h (revision 2861)
@@ -201,6 +201,14 @@
#define PERL_MG_UFUNC(name,ix,sv) I32 name(IV ix, SV *sv)
#endif
+/* Post 5.13.3 */
+#ifndef CvGV_set
+# define CvGV_set(cv, gv) (CvGV(cv) = (gv))
+#endif
+#ifndef GvCV_set
+# define GvCV_set(gv, cv) (GvCV(gv) = (cv))
+#endif
+
#ifdef eval_pv
# ifndef perl_eval_pv
# define perl_eval_pv eval_pv
Index: src/modules/perl/perl_config.c
===
--- src/modules/perl/perl_config.c (revision 2779)
+++ src/modules/perl/perl_config.c (revision 2861)
@@ -1721,7 +1721,7 @@
if((cv = GvCV((GV*)val)) (GvSTASH((GV*)val) == GvSTASH(CvGV(cv {
GV *gv = CvGV(cv);
cv_undef(cv);
-CvGV(cv) = gv;
+CvGV_set(cv, gv);
GvCVGEN(gv) = 1; /* invalidate method cache */
}
}
Index: src/modules/perl/Log.xs
===
--- src/modules/perl/Log.xs (revision 2779)
+++ src/modules/perl/Log.xs (revision 2861)
@@ -10,7 +10,7 @@
static void perl_cv_alias(char *to, char *from)
{
GV *gp = gv_fetchpv(to, TRUE, SVt_PVCV);
-GvCV(gp) = perl_get_cv(from, TRUE);
+GvCV_set(gp, perl_get_cv(from, TRUE));
}
static void ApacheLog(int level, SV *sv, SV *msg)
Index: src/modules/perl/Apache.xs
Index: Symbol/Symbol.xs
===
--- Symbol/Symbol.xs(revision 2779)
+++ Symbol/Symbol.xs(revision 2861)
@@ -2,6 +2,10 @@
#include perl.h
#include XSUB.h
+#ifndef CvGV_set
+# define CvGV_set(cv, val) (CvGV(cv) = val)
+#endif
+
#ifdef PERL_OBJECT
#define sv_name(svp) svp
#define undef(ref)
@@ -30,7 +34,7 @@
has_proto = TRUE;
cv_undef(cv);
- CvGV(cv) = gv; /* let user-undef'd sub keep its identity */
+CvGV_set(cv,gv); /* let user-undef'd sub keep its identity */
if(has_proto)
SvPOK_on(cv); /* otherwise we get `Prototype mismatch:' */
