If your program opens a hardcoded file at "/tmp/foo.bar", then it won't work on Windows (which is why the Java cross-platform standards say you can't hardcode file paths).

Other programs may make subtle assumptions about the word size (32-bits vs. 64-bits).

Doing unlink $file won't delete the file on systems that have versioned filesystems (like VMS). In such a case, unlinking the file returns it to the previous version. You have to do while(-e $file) { unlink $file } to completely get rid of it.

Cross-platform issues are often subtle and cover a wider range of cases than any one programmer could possibly remember. The only real way to know is to try it on the platform and test throughly.

The perl interpreter is compiled and runs on the native architecture.

The Perl script is a completely different beast: it's the text file that you pass around. Text doesn't care what system it's on, unless you tell that text to do something system-dependent.

That is how I understand it. It depends on what the text has in it.

Time to dig deep into rsnapshot

Walking the road to enlightenment... I found a penguin and a camel on the way.....
Fancy a yourname@perl.me.uk? Just ask!!!

Certain things behave, or can behave different on different OSses. For details, see "perlport.pod". So while many perl scripts will run fine (and identical) on any platform perl runs on, some perl programs won't. So putting it in i386 makes sense.

I think the answer is probably "Yes, most of the time."

Perl releases are tested on a variety of platforms and (I imagine) are tweaked until all tests pass. Thus, a program that uses core Perl only should be architecture neutral.

Things may get interesting when CPAN modules are used -- I don't have any idea how they are tested on different platforms.

I don't think you're asking about platform dependence in the usual way. When you talk about moving between different OS platforms (e.g. Windows to Linux or vice-versa), Perl can be platform-independent, if the developer chooses not to use platform-specific code.

But, it appears you're talking about using the same OS (Fedora) on different hardware. The answer is simple: Perl scripts are interpreted, so as long as the interpreter works on that hardware, your script will too. Module use shouldn't even be affected, though XS modules may have to be compiled for that architecture.

In short, Perl scripts are architecture-independent (so long as there is a working interpreter) by default, but are platform-independent through careful programming. (architecture is the hardware, platform is the OS and related components).

Yes, sorry. The same OS, but on different hardware.

"The answer is simple: Perl scripts are interpreted, so as long as the interpreter works on that hardware, your script will too."

As long as that version of Perl, supports the features used in that script, yes.

But in my situation, it will be the same Perl core, just different hardware, so you are right. Thanks.

Walking the road to enlightenment... I found a penguin and a camel on the way.....
Fancy a yourname@perl.me.uk? Just ask!!!

The only Perl modules that shouldn't be architecture-independent for the purpose of RPM are ones that use XS. But it's pretty clear from how the question was asked that there's no XS involved here. Your script could depend on modules that use XS, and hence are architecture-specific, but that's no reason to make your script architecture-specific unless you bundle those modules with your script's distribution.

Labelling those dependencies is another problem. It seems like older perl RPMs provided things like "XML::Simple" or maybe it was "perl-XML-Simple". Newer ones now seem to instead provide "perl(XML::Simple)".