can perl modules be used by various versions of perl?

Discussion in 'Perl Misc' started by garey, May 25, 2007.

  1. garey

    garey Guest

    Hello -

    I have an application that will move between two machines. It
    will normally run on the first machine; if the machine or the
    application fails, the application and the directory structure that
    contains it will move to the second machine.

    In the application I use several PERL modules. I have an
    installation of PERL on each machine, and at the moment, both
    installations are version 5.8.8.

    My worry is that, if at some point the PERL versions
    inadvertently get out of sync, the PERL modules will stop functioning
    correctly, because the PERL modules only work with one version of
    PERL.

    So my question is 'what is the relation between a PERL module and
    the PERL it was compiled with?'. Is there a wide range of PERL
    versions a particular module will work with? or is the PERL module
    limited to working only with the PERL in whose library it is found?

    I can't find any documentation that states how this works,
    probably because the answer is so obvious. But not to me.

    Any help would be appreciated;

    Garey Mills
    garey, May 25, 2007
    #1
    1. Advertising

  2. garey

    brian d foy Guest

    In article <>,
    garey <> wrote:

    > So my question is 'what is the relation between a PERL module and
    > the PERL it was compiled with?'.


    It depends on the module. Pure Perl modules might not have a problem,
    although syntax varies in minor versions as new features are
    added.

    Modules that relied on compiled components (e.g. XS, SWIG, etc) are
    probably okay on different machines running the same versions of
    everything (including the same operatiing system) that were compiled in
    the same way. Perl's within a minor version release (5.8.6, 5.8.8)
    should be okay.

    Other than that, I would expect and plan on things not being compatible.

    --
    Posted via a free Usenet account from http://www.teranews.com
    brian d foy, May 25, 2007
    #2
    1. Advertising

  3. garey

    Tim S Guest

    garey wrote:

    > Hello -
    >
    > I have an application that will move between two machines. It
    > will normally run on the first machine; if the machine or the
    > application fails, the application and the directory structure that
    > contains it will move to the second machine.
    >
    > In the application I use several PERL modules. I have an
    > installation of PERL on each machine, and at the moment, both
    > installations are version 5.8.8.
    >
    > My worry is that, if at some point the PERL versions
    > inadvertently get out of sync, the PERL modules will stop functioning
    > correctly, because the PERL modules only work with one version of
    > PERL.
    >
    > So my question is 'what is the relation between a PERL module and
    > the PERL it was compiled with?'. Is there a wide range of PERL
    > versions a particular module will work with? or is the PERL module
    > limited to working only with the PERL in whose library it is found?
    >
    > I can't find any documentation that states how this works,
    > probably because the answer is so obvious. But not to me.
    >
    > Any help would be appreciated;
    >
    > Garey Mills


    Perl isn't compiled per-se (well not in the way that python is to a .pyc or
    java to a .class). It is pseudo-compiled to perl bytecode upon every
    invocation of the script[1].

    As to version, with a little care it's not hard to have perl script that is
    good for 5.6.1 through 5.8.8. You get some funnies like 5.6 doesn't like:

    use constant
    {
    foo => 'bar',
    bar => 'foo',
    };

    when it's OK for some later version, but:

    use constant foo => 'bar';
    use constant bar => 'foo';

    is find on both.

    Perl has a pretty good record on compatibility. When I was working at
    Imperial College London, we had scripts that ran off NFS mounts that worked
    fine across random perl versions on Linux and Solaris covering 5.6.x to
    5.8.6.

    XS modules may be more delicate, but not too dire.

    This is why sysadmins tend to like perl: CPAN + a certain degree of
    constancy makes for a reliable and useful language.

    HTH

    Tim

    [1] Perl d00dz are probably going to say: what about B::Bytecode?
    Don't care, sysadmins don't usually try that trick ;->
    Tim S, May 25, 2007
    #3
  4. garey

    Joe Smith Guest

    garey wrote:

    > So my question is 'what is the relation between a PERL module and
    > the PERL it was compiled with?'. Is there a wide range of PERL
    > versions a particular module will work with? or is the PERL module
    > limited to working only with the PERL in whose library it is found?


    For the most part, newer versions of Perl are upward-compatible - the
    new version runs the old code just fine. Possible exceptions are binary modules.

    When a new major version comes out (such as going from 5.6.x to 5.8.x),
    modules written in C (or other language that creates a *.so file)
    might not work until re-compiled for the new version.

    Take a look at the output from

    find /usr/lib/perl5 -name '*.so' -print

    to see if any of the modules you're currently using fit into that category.
    -Joe
    Joe Smith, May 29, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rob Nicholson
    Replies:
    4
    Views:
    348
    Rob Nicholson
    Aug 9, 2004
  2. Rob R. Ainscough
    Replies:
    1
    Views:
    489
    intrader
    Jun 25, 2005
  3. Kartic
    Replies:
    3
    Views:
    336
    Efrat Regev
    Feb 24, 2005
  4. Casey Hawthorne
    Replies:
    1
    Views:
    708
    Arne Vajhøj
    Mar 18, 2009
  5. Ted Byers
    Replies:
    23
    Views:
    419
    Peter J. Holzer
    Nov 15, 2008
Loading...

Share This Page