in reply to Re^4: Installing (lotsa) modules
in thread Installing (lotsa) modules

"Binary" modules (those using XS) usually not only depend on the exact perl version and its configuration

Interestingly, I think "exact perl version" slightly overstates the condition.
AFAIK, a package built for perl-5.x.y will be fine with perl-5.a.b, so long as x == a. (But no need for y == b. However, I can't recall if there was also a need for y <= b. Anyone ? )
This meant, for example, that having built a Windows PPM package of a perl module for (say) perl-5.30.0, that same binary package would be fine for all 5.30.* versions of perl on Windows - so long as all of these perl-5.30.* versions had been configured the same.

At least, that's the way it used to be - but I haven't tested to see whether the XS handshake tests that were added a couple of years ago might now interfere with that capability.
If they do interfere, then they do so for no valid reason that I know of.

Cheers,
Rob

Replies are listed 'Best First'.
Re^6: Installing (lotsa) modules
by Corion (Patriarch) on Jan 25, 2021 at 08:00 UTC

    Yes, in general, 5.x.z will be compatible with 5.x.y. Changes that break this compatibility ("binary compatibility") should not get backported.

    Of course, this only holds true for identical configuration options, either in the Win32/Makefile or via Configure. If you configure a Perl differently (with/without threads, different float sizes, ...), you won't get compatibility between Perl versions, or within the same Perl version even.

    Now that I think/write about this, I don't think there is a real test between Perl versions at release time to ensure that compatibility test. I think the smoke testers will find out such a breaking change quickly, but a (manual) test step should be good there ...

[reply]
[d/l]
[select]
      Of course, this only holds true for identical configuration options

      I thought this was too good to be true...
      So I won't be able to bundle compiled modules on a Windows 10 machine and make then available on an unidentified Linux virtual machine (shared web host) which doesn't have (access to) a complier.

[reply]

        Well, it is possible, in theory, if you cross-compile the modules on Windows for the target Linux. But it is very unlikely, and a lot of work, compared to trying to build a Perl similar to the unidentified Linux machine in a VM.

        To do that, I would run perl -V (or perl -MConfig -MData::Dumper -e 'print Dumper \%Config', or the mod_perl equivalent), to get at the configure line (config_args), and then potentially look at the integer and float sizes (ivsize, nvsize).

        use 5.012;
use Config;

say $Config{config_args};
say $Config{nvsize};
say $Config{ivsize};

        [download]

        Building a Perl with parameters identical to these (or even one where the whole of Config_heavy.pl matches the one on the unidentified Linux VM) is likely to yield compatible modules you can just upload.

        Ideally, I will be merely

        1. Download the appropriate Perl version as tarball in your VM
        2. Unpack the tarball in your VM: 
                  tar xjf perl-5.32.1.tar.xz

          [download]
        3. Configure Perl. Maybe you can find a leftover Policy.sh or config.sh in the unnamed Linux server. Otherwise start with the output of perl -MConfig -e 'print $Config{config_args}' (from the unnamed Linux machine). Try different things until you get the generated Config_heavy.pl to match up with the one from tne unnamed Linux machine. 
          sh Configure ...

          [download]
        4. Test and install Perl: 
          make test
make install

          [download]
        5. Compile your own, hopefully compatible modules for the remote side.
[reply]
[d/l]
[select]

        You can't compile XS code on Windows and move it to Linux. As mentioned previously, run a VM locally the same OS and architecture as your target, that way you can compile in a fairly straight forward manner, and transfer to your host.

[reply]

In Section Seekers of Perl Wisdom