|
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 |
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] |
|
|
| [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};
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
- Download the appropriate Perl version as tarball in your VM
- Unpack the tarball in your VM:
tar xjf perl-5.32.1.tar.xz
-
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 ...
-
Test and install Perl:
make test
make install
- 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] |
|
|
|
|
|
|
| |
|
|
|
|
|
|
