mod_perl-1.31 compilation with perl 5.14.1 fails

--90e6ba3fd5fd13334b04a6ba47d9
Content-Type: text/plain; charset=ISO-8859-1

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

eg. http://cpansearch.perl.org/src/GOZER/mod_perl-1.31/Symbol/Sy mbol.xs

Symbol.xs: In function 'undef':
Symbol.xs:33: error: invalid lvalue in assignment



This appears to be due to changes in the perl distro as outlined at
http://perldoc.perl.org/perl5140delta.html#C-API-Changes

GvCV() and GvGP() are no longer lvalues

The new GvCV_set() and GvGP_set() macros are now provided to replace
assignment to those two macros.

This allows a future commit to eliminate some backref magic between GV and
CVs, which will require complete control over assignment to the gp_cv slot.
CvGV() is no longer an lvalue

Under some circumstances, the CvGV() field of a CV is now reference-counted.
To ensure consistent behaviour, direct assignment to it, for example CvGV(cv
) = gv is now a compile-time error. A new macro, CvGV_set(cv,gv)has been
introduced to run this operation safely. Note that modification of this
field is not part of the public API, regardless of this new macro (and
despite its being listed in this section).
CvSTASH() is no longer an lvalue

The CvSTASH() macro can now only be used as an rvalue. CvSTASH_set() has
been added to replace assignment to CvSTASH(). This is to ensure that
backreferences are handled properly. These macros are not part of the API.


Any witnesses/experiences/thoughts on this?

thanks in advance!
gleeco

--90e6ba3fd5fd13334b04a6ba47d9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

hello - am getting compilation errors in building older mod_perl with newer=
perl.=A0 Things worked as of 5.12.X, but alas, not with today's 5.14.1=


eg. Symbol/Symbol.xs">http://cpansearch.perl.org/src/GOZER/mod_p erl-1.31/Symbol=
/Symbol.xs


Symbol.xs: In funct=
ion 'undef':
">Symbol.xs:33: error: =
invalid lvalue in assignment




This appears to be due to changes in the perl distro as outline=
d at h=
ttp://perldoc.perl.org/perl5140delta.html#C-API-Changes

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 =E0 16:54 -0700, Gregory Coleman a =E9crit :
> > 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
> >
> >=20
> >
> > Any witnesses/experiences/thoughts on this?=20
> >
> >=20
>=20
> Some in this thread :
>=20
> 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=20
with SvGP and SvCV used in lvalue context, see also

https://rt.cpan.org/Ticket/Display.html?id=3D64999

I doubt that any one of the current dev team will incorporate these=20
changes into mp1. Though, if someone provides patches I think there are=20
good chances for them to get applied especially if that someone wants to=20
take care of mp1 in the future and thus become a committer.

Torsten Förtsch

=2D-=20
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 wrote=
:
> Le lundi 27 juin 2011 =E0 16:54 -0700, Gregory Coleman a =E9crit :
>> hello - am getting compilation errors in building older mod_perl with
>> newer perl. =A0Things 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 :
> On Tuesday, June 28, 2011 11:57:47 Vincent Veyron wrote:
>> Le lundi 27 juin 2011 =E0 16:54 -0700, Gregory Coleman a =E9crit :
>> > hello - am getting compilation errors in building older mod_perl
>> > with newer perl. =A0Things 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:
>
> =A0http://www.gossamer-threads.com/lists/modperl/modperl/101 027
>
> There were a few incompatible code changes in perl 5.14, particularly
> with SvGP and SvCV used in lvalue context, see also
>
> =A0https://rt.cpan.org/Ticket/Display.html?id=3D64999
>
> 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

This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_tamara-18040-1309304475-0001-2
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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.








--=_tamara-18040-1309304475-0001-2
Content-Type: text/plain; name="mp1-501303.patch"; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="mp1-501303.patch"

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:' */


--=_tamara-18040-1309304475-0001-2--

Re: mod_perl-1.31 compilation with perl 5.14.1 fails

According to Fred Moyer 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: web@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 wrote:
> According to Fred Moyer on Tue, 06/28/11 at 16:5=
0:
>> >
>> > 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. =A0No specific 5.14 incompatibilities were
>> identified.
>
> I am a bit surprised by your summary of my problem. =A0I 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 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: web@umich.edu

72 characters width template ----------------------------------------->|

Re: mod_perl-1.31 compilation with perl 5.14.1 fails

On Mon, Jun 27, 2011 at 4:54 PM, Gregory Coleman
wrote:
> hello - am getting compilation errors in building older mod_perl with new=
er
> perl.=A0 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=3D1 option with 'perl Makefile.PL'.

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=3D64999#txn-9 54785

On Mon, Jul 4, 2011 at 10:20 AM, Fred Moyer wrote:
> On Mon, Jun 27, 2011 at 4:54 PM, Gregory Coleman
> wrote:
>> hello - am getting compilation errors in building older mod_perl with ne=
wer
>> perl.=A0 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. =A0I
> used the EVERYTHING=3D1 option with 'perl Makefile.PL'.
>

Re: mod_perl-1.31 compilation with perl 5.14.1 fails

On Mon, Jul 11, 2011 at 11:39 PM, Fred Moyer wrote=
:
> Looks like a patch for this issue was posted. =A0Greg, do you want to
> try out this patch and report back?
>
> https://rt.cpan.org/Public/Bug/Display.html?id=3D64999#txn-9 54785

This patch fixed it for me on CentOS.

- Perrin

Re: mod_perl-1.31 compilation with perl 5.14.1 fails

On Tue, Jul 12, 2011 at 12:36 PM, Perrin Harkins wrote:
> On Mon, Jul 11, 2011 at 11:39 PM, Fred Moyer wro=
te:
>> Looks like a patch for this issue was posted. =A0Greg, do you want to
>> try out this patch and report back?
>>
>> https://rt.cpan.org/Public/Bug/Display.html?id=3D64999#txn-9 54785
>
> 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!