perlport - Writing portable Perl
Perl runs on numerous operating systems. While most of them share much in common, they also
have their own unique features.
This document is meant to help you to find out what constitutes portable Perl code. That
way once you make a decision to write portably, you know where the lines are drawn, and you
can stay within them.
There is a tradeoff between taking full advantage of one particular type of computer and
taking advantage of a full range of them. Naturally, as you broaden your range and become more
diverse, the common factors drop, and you are left with an increasingly smaller area of common
ground in which you can operate to accomplish a particular task. Thus, when you begin
attacking a problem, it is important to consider under which part of the tradeoff curve you
want to operate. Specifically, you must decide whether it is important that the task that you
are coding have the full generality of being portable, or whether to just get the job done
right now. This is the hardest choice to be made. The rest is easy, because Perl provides many
choices, whichever way you want to approach your problem.
Looking at it another way, writing portable code is usually about willfully limiting your
available choices. Naturally, it takes discipline and sacrifice to do that. The product of
portability and convenience may be a constant. You have been warned.
Be aware of two important points:
- Not all Perl programs have to be
- There is no reason you should not use Perl as a language to glue Unix tools together, or
to prototype a Macintosh application, or to manage the Windows registry. If it makes no
sense to aim for portability for one reason or another in a given program, then don't
- Nearly all of Perl already is
- Don't be fooled into thinking that it is hard to create portable Perl code. It isn't.
Perl tries its level-best to bridge the gaps between what's available on different
platforms, and all the means available to use those features. Thus almost all Perl code
runs on any machine without modification. But there are some significant issues in writing
portable code, and this document is entirely about those issues.
Here's the general rule: When you approach a task commonly done using a whole range of
platforms, think about writing portable code. That way, you don't sacrifice much by way of the
implementation choices you can avail yourself of, and at the same time you can give your users
lots of platform choices. On the other hand, when you have to take advantage of some unique
feature of a particular platform, as is often the case with systems programming (whether for
Unix, Windows, Mac OS, VMS, etc.), consider writing platform-specific code.
When the code will run on only two or three operating systems, you may need to consider
only the differences of those particular systems. The important thing is to decide where the
code will run and to be deliberate in your decision.
The material below is separated into three main sections: main issues of portability ("ISSUES", platform-specific issues ("PLATFORMS",
and built-in perl functions that behave differently on various ports ("FUNCTION IMPLEMENTATIONS".
This information should not be considered complete; it includes possibly transient
information about idiosyncrasies of some of the ports, almost all of which are in a state of
constant evolution. Thus, this material should be considered a perpetual work in progress (
SRC="yellow_sign.gif" ALT="Under Construction">).
Modules uploaded to CPAN are tested by a variety of volunteers on different platforms.
These CPAN testers are notified by mail of each new upload, and reply to the list with PASS,
FAIL, NA (not applicable to this platform), or UNKNOWN (unknown), along with any relevant
The purpose of the testing is twofold: one, to help developers fix any problems in their
code that crop up because of lack of testing on other platforms; two, to provide users with
information about whether a given module works on a given platform.
- Mailing list: email@example.com
- Testing results: http://testers.cpan.org/
- v1.48, 02 February 2001
- Various updates from perl5-porters over the past year, supported platforms update from
- v1.47, 22 March 2000
- Various cleanups from Tom Christiansen, including migration of long platform listings
- v1.46, 12 February 2000
- Updates for VOS and MPE/iX. (Peter Prymmer) Other small changes.
- v1.45, 20 December 1999
- Small changes from 5.005_63 distribution, more changes to EBCDIC info.
- v1.44, 19 July 1999
- A bunch of updates from Peter Prymmer for
$^O values, endianness,
File::Spec, VMS, BS2000, OS/400.
- v1.43, 24 May 1999
- Added a lot of cleaning up from Tom Christiansen.
- v1.42, 22 May 1999
- Added notes about tests, sprintf/printf, and epoch offsets.
- v1.41, 19 May 1999
Lots more little changes to formatting and content.
Added a bunch of
$^O and related values for various platforms; fixed mail
and web addresses, and added and changed miscellaneous notes. (Peter Prymmer)
- v1.40, 11 April 1999
- Miscellaneous changes.
- v1.39, 11 February 1999
- Changes from Jarkko and EMX URL fixes Michael Schwern. Additional note about newlines
- v1.38, 31 December 1998
- More changes from Jarkko.
- v1.37, 19 December 1998
- More minor changes. Merge two separate version 1.35 documents.
- v1.36, 9 September 1998
- Updated for Stratus VOS. Also known as version 1.35.
- v1.35, 13 August 1998
- Integrate more minor changes, plus addition of new sections under "ISSUES":
"Numbers endianness and Width", "Character sets and character
- v1.33, 06 August 1998
- Integrate more minor changes.
- v1.32, 05 August 1998
- Integrate more minor changes.
- v1.30, 03 August 1998
- Major update for RISC OS, other minor changes.
- v1.23, 10 July 1998
- First public release with perl5.005.
As of June 2002 (the Perl release 5.8.0), the following platforms are able to build Perl
from the standard source code distribution available at http://www.cpan.org/src/index.html
DOS DJGPP 1)
Mac OS Classic
Mac OS X (Darwin)
Tru64 UNIX (DEC OSF/1, Digital UNIX)
1) in DOS mode either the DOS or OS/2 ports can be used
2) compilers: Borland, MinGW (GCC), VC6
The following platforms worked with the previous releases (5.6 and 5.7), but we did not
manage either to fix or to test these in time for the 5.8.0 release. There is a very good
chance that many of these will work fine with the 5.8.0.
Known to be broken for 5.8.0 (but 5.6.1 and 5.7.2 can be used):
The following platforms have been known to build Perl from source in the past (5.005_03 and
earlier), but we haven't been able to verify their status for the current release, either
because the hardware/software platforms are rare or because we don't have an active champion
on these platforms--or both. They used to work, though, so go ahead and try compiling them,
and let firstname.lastname@example.org of any trouble.
The following platforms have their own source code distributions and binaries available via
Tandem Guardian 5.004
The following platforms have only binaries available via http://www.cpan.org/ports/index.html
Acorn RISCOS 5.005_02
Although we do suggest that you always build your own Perl from the source code, both for
maximal configurability and for security, in case you are in a hurry you can check http://www.cpan.org/ports/index.html
for binary distributions.
Abigail <email@example.com>, Charles Bailey <firstname.lastname@example.org>, Graham
Barr <email@example.com>, Tom Christiansen <firstname.lastname@example.org>, Nicholas Clark
<email@example.com>, Thomas Dorner <Thomas.Dorner@start.de>, Andy Dougherty <firstname.lastname@example.org>,
Dominic Dunlop <email@example.com>, Neale Ferguson <firstname.lastname@example.org>,
David J. Fiander <email@example.com>, Paul Green <Paul_Green@stratus.com>, M.J.T. Guy
<firstname.lastname@example.org>, Jarkko Hietaniemi <email@example.com>, Luther Huffman <firstname.lastname@example.org>,
Nick Ing-Simmons <email@example.com>, Andreas J. König <firstname.lastname@example.org>,
Markus Laker <email@example.com>, Andrew M. Langmead <firstname.lastname@example.org>, Larry
Moore <email@example.com>, Paul Moore <Paul.Moore@uk.origin-it.com>, Chris
Nandor <firstname.lastname@example.org>, Matthias Neeracher <email@example.com>, Philip Newton
<firstname.lastname@example.org>, Gary Ng <71564.1743@CompuServe.COM>, Tom Phoenix <email@example.com>,
André Pirard <A.Pirard@ulg.ac.be>, Peter Prymmer <firstname.lastname@example.org>, Hugo van der
Sanden <email@example.com>, Gurusamy Sarathy <firstname.lastname@example.org>, Paul J.
Schinder <email@example.com>, Michael G Schwern <firstname.lastname@example.org>, Dan Sugalski
<email@example.com>, Nathan Torkington <firstname.lastname@example.org>.