mod_perl and parallel Perl versions

[Gunnar Hjalmarsson]

I have installed Perl 5.10.0 on my Linux box to be available together
with the vendor supplied Perl 5.8.1. When running programs under
mod_perl, the old Perl version is utilized.

How can I make mod_perl use Perl 5.10.0? Can mod_perl be configured so I
can select Perl version on-the-fly?

 

[Ben Morrow]

I have installed Perl 5.10.0 on my Linux box to be available together
with the vendor supplied Perl 5.8.1. When running programs under
mod_perl, the old Perl version is utilized.

How can I make mod_perl use Perl 5.10.0? Can mod_perl be configured so I
can select Perl version on-the-fly?

5.10 is not binary-compatible with 5.8, so you will need to rebuild
mod_perl against 5.10. AIUI, mod_perl needs to be rebuilt against a new
version of perl anyway, as it does a lot of poking around in
undocumented parts of perls guts.

Ben

 

[Gunnar Hjalmarsson]

Recompile & reinstall mod_perl.

Yep, it proved to be that simple.

No, the Apache module is linked to libperl, so it's specific to that Perl
for the reason that an XS module is - libperl exports a different set of
public symbols from one version to the next, and hides the differences
behind an API that's almost entirely cpp macros.

I noticed that /usr/lib/httpd/modules/mod_perl.so was overwritten during
the installation; guess that's part of it...

If you're looking for a more performant CGI replacement, you might look
at FastCGI instead. The cost in terms of IPC between Apache and the app
server are minimal, and like mod_perl it's a persistent environment, but
like CGI, you simply use the #! line to choose a language interpreter.

Maybe I should have a look at FastCGI. Thanks for the tip!

And thanks both Ben and Sherman for your help.

 

[Ben Morrow]

That appears to no longer be the case - mod_perl 2.0.4 was released just a
couple days ago, and one of the listed changes is that "it works with 5.10."

Read what I said again. I said you will need to *rebuild* mod_perl
against 5.10: attempting to use a version built against 5.8 with perl
5.10 definitely won't work (this applies generally to any XS module).
The fact that versions <2.0.4 won't work with 5.10 even then I didn't
address (because I didn't know ).

Ben

 

[Ben Morrow]

What you said makes no sense when taken at face value.

Ordinary XS modules are not binary-compatible, and need to be rebuilt - but
that's *always* the case, and it's not the result of using any undocumented
calls. Mod_perl does use undocumented calls, but it needed to be ported as
a result of that, not simply rebuilt.

OK, perhaps I should be clearer.

Perl versions 5.8.1 through 5.8.8 were considered 'binary-compatible' by
p5p. Most XS modules built against 5.8.1 will work correctly with 5.8.8
without rebuilding. This is not true of mod_perl: since it uses
undocumented calls, it requires rebuilding for *any* change in perl
version, even one advertised by p5p as 'binary-compatible'.

Perl version 5.10 is considered by p5p to break binary compatibility.
All XS modules, mod_perl included, will need to be rebuilt. Perl
versions 5.10.x will, almost certainly, be binary-compatible with
5.10.0, so again modules *other* than mod_perl won't need to be rebuilt.

In my original reply I confused the '5.10 is binary-incompatible with
5.8' and the 'mod_perl is never binary-compatible under any change in
perl version' parts of the above.

I chose the most charitable interpretation that made sense - that you're
aware of the situation and simply mistyped "rebuild" when you were actually
referring to the porting effort.

Thank you for your charity , but I wasn't and didn't. The
clarification is appreciated.

Ben