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.

Perl -V

Read more... (11 kB)

Update:

config_args

-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexception
+s -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-swi
+tches   -m64 -mtune=generic -Dccdlflags=-Wl,--enable-new-dtags -Dlddl
+flags=-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
+ -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-swit
+ches   -m64 -mtune=generic -Wl,-z,relro  -DDEBUGGING=-g -Dversion=5.1
+6.3 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_b
+y=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/l
+ocal -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/per
+l5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_per
+l -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_per
+l -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib
+64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/us
+r/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdb
+m -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl
+=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_getho
+stent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endpr
+otoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_set
+servent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize

nvsize = 8

ivsize = 8
[download]

Cool - so now you should be able to build a (Linux) Perl that is identically configured as your target Perl. Then you can use your local Perl to compile modules for your remote Perl, as I described in my original reply.

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.

This is why package management systems such as deb, RPM, ports, and so on were invented. The software could be built once and installed many times. There was even one available for Solaris!. For example, both Fedora and Ubuntu have over 3000 perl modules waiting to be installed.

Not from Windows to *NIX, you can't just copy binary stuff built on one and expect it to work on the other. Reading OPs post history will reveal current hosting limitations.

If I'm not mistaken, these build systems rely on the system perl. I never, ever allow anything to come remotely close to my system perl (or python etc).

run a VM locally the same OS and architecture as your target

Therein lies the difficulty...I have no idea of either the OS (other than Linux) or architecture of the target virtual machine.

It is not something I am going to spend much time on.
When it becomes mission critical, and when my Linux confidence improves, I will upgrade to VPS or dedicated server which will make the issue obsolete.

"have no idea of either the OS (other than Linux) or architecture of the target virtual machine."

If only we as a species had one (or more) ways to search for answers to such things :P