Seth Woolley's Man Viewer

perlmacosx(1) - README.macosx - Perl under Mac OS X - man 1 perlmacosx

([section] manual, -k keyword, -K [section] search, -f whatis)
man plain no title

PERLMACOSX(1)          Perl Programmers Reference Guide          PERLMACOSX(1)

       README.macosx - Perl under Mac OS X

       This document briefly describes perl under Mac OS X.

       The latest Perl (5.8.1-RC3 as of this writing) builds without changes
       under Mac OS X. Under the 10.3 "Panther" release, all self-tests pass,
       and all standard features are supported.

       Earlier Mac OS X releases did not include a completely thread-safe
       libc, so threading is not fully supported. Also, earlier releases
       included a somewhat buggy libdb, so some of the DB_File tests are known
       to fail on those releases.

       Installation Prefix

       The default installation location for this release uses the traditional
       UNIX directory layout under /usr/local. This is the recommended loca-
       tion for most users(1,5), and will leave the Apple-supplied Perl and its
       modules undisturbed.

       Using an installation prefix of '/usr' will result in(1,8) a directory lay-
       out that mirrors that of Apple's default Perl, with core modules stored
       in(1,8) '/System/Library/Perl/${version(1,3,5)}', CPAN modules stored in(1,8)
       '/Library/Perl/${version(1,3,5)}', and the addition of '/Net-
       work/Library/Perl/${version(1,3,5)}' to @INC for modules that are stored on a
       file(1,n) server and used by many Macs.

       libperl and Prebinding

       Mac OS X ships with a dynamically-loaded libperl, but the default for
       this release is to compile a static libperl. The reason for this is
       pre-binding. Dynamic libraries can be pre-bound to a specific address
       in(1,8) memory in(1,8) order to decrease load(7,n) time. To do this, one needs to be
       aware of the location and size of all previously-loaded libraries.
       Apple collects this information as part of their overall OS build
       process, and thus has easy access(2,5) to it when building Perl, but ordi-
       nary users(1,5) would need to go to a great deal of effort to obtain the
       information needed for pre-binding.

       You can override the default and build a shared libperl if(3,n) you wish
       (Configure ... -Duseshrlib), but the load(7,n) time(1,2,n) will be significantly
       greater than either the static library, or Apple's pre-bound dynamic

       Updating Panther

       As of this writing, the latest Perl release that has been tested and
       approved for inclusion in(1,8) the 10.3 "Panther" release of Mac OS X is
       5.8.1 RC3. It is currently unknown whether the final 5.8.1 release will
       be made in(1,8) time(1,2,n) to be tested and included with Panther.

       If the final release of Perl 5.8.1 is not made in(1,8) time(1,2,n) to be included
       with Panther, it is recommended that you wait for an official Apple
       update(7,n) to the OS, rather than attempting to update(7,n) it yourself. In most
       cases, if(3,n) you need a newer Perl, it is preferable to install it in(1,8) some
       other location, such as /usr/local or /opt, rather than overwriting the
       system Perl.  The default location (no -Dprefix=... specified when run-
       ning Configure) is /usr/local.

       If you find that you do need to update(7,n) the system Perl, there is one
       potential issue. If you upgrade using the default static libperl, you
       will find that the dynamic libperl supplied by Apple will not be
       deleted. If both libraries are present when an application that links
       against libperl is built, ld(1,8) will link(1,2) against the dynamic library by
       default. So, if(3,n) you need to replace Apple's dynamic libperl with a
       static libperl, you need to be sure to delete the older dynamic library
       after you've installed the update.

       Note that this is only an issue when updating from an older build of
       the same Perl version. If you're updating from (for example) 5.8.1 to
       5.8.2, this issue won't affect you.

       Known problems

       If you have installed extra libraries such as GDBM through Fink (in(1,8)
       other words, you have libraries under /sw/lib), or libdlcompat to
       /usr/local/lib, you may need to be extra careful when running Configure
       to not to confuse Configure and Perl about which libraries to use.
       Being confused will show up for example as "dyld" errors about symbol
       problems, for example during "make test". The safest bet is to run Con-
       figure as

           Configure ... -Uloclibpth -Dlibpth=/usr/lib

       to make Configure look(1,8,3 Search::Dict) only into the system libraries.  If you have
       some extra library directories that you really want to use (such as
       newer Berkeley DB libraries in(1,8) pre-Panther systems), add those to the

           Configure ... -Uloclibpth -Dlibpth='/usr/lib /opt/lib'

       The default of building Perl statically may cause problems with complex
       applications like Tk: in(1,8) that case consider building shared Perl

           Configure ... -Duseshrplib

       but remember that there's a startup cost to pay in(1,8) that case (see above
       "libperl and Prebinding").


       Quite a bit has been written about MacPerl, the Perl distribution for
       "Classic MacOS" - that is, versions 9 and earlier of MacOS. Because it
       runs in(1,8) environment that's very different from that of UNIX, many
       things are done differently in(1,8) MacPerl. Modules are installed using a
       different procedure, Perl itself is built differently, path names are
       different, etc.

       From the perspective of a Perl programmer, Mac OS X is more like a tra-
       ditional UNIX than Classic MacOS. If you find documentation that refers
       to a special procedure that's needed for MacOS that's drastically dif-
       ferent from the instructions provided for UNIX, the MacOS instructions
       are quite often intended for MacPerl on Classic MacOS. In that case,
       the correct procedure on Mac OS X is usually to follow the UNIX
       instructions, rather than the MacPerl instructions.


       MacPerl ships with a number of modules that are used to access(2,5) the
       classic MacOS toolbox. Many of these modules have been updated to use
       Mac OS X's newer "Carbon" toolbox, and are available from CPAN in(1,8) the
       "Mac::Carbon" module.


       There are two ways to use Cocoa from Perl. Apple's PerlObjCBridge mod-
       ule, included with Mac OS X, can be used by standalone scripts to
       access(2,5) Foundation (i.e. non-GUI) classes and objects.

       An alternative is CamelBones, a framework that allows access(2,5) to both
       Foundation and AppKit classes and objects, so that full GUI applica-
       tions can be built in(1,8) Perl. CamelBones can be found on SourceForge, at

Starting From Scratch
       Unfortunately it is not that difficult somehow manage to break one's
       Mac OS X Perl rather severely.  If all else fails and you want to
       really, REALLY, start from scratch and remove even your Apple Perl
       installation (which has become corrupted somehow), the following
       instructions should do it.  Please think twice before following these
       instructions: they are much like conducting brain surgery to yourself.
       Without anesthesia.  We will not come to fix your system if(3,n) you do

       First, get rid of the libperl.dylib:

           # cd /System/Library/Perl/darwin/CORE
           # rm libperl.dylib

       Then delete every .bundle file(1,n) found anywhere in(1,8) the folders:


       You can find them for example by

           # find /System/Library/Perl /Library/Perl -name '*.bundle' -print

       After this you can either copy Perl from your operating system CDs (you
       will need at least the /System/Library/Perl and /usr/bin/perl), or
       rebuild Perl from the source code with "Configure -Dprefix=/usr -Duser-
       shrplib" NOTE: the "-Dprefix=/usr" to replace the system Perl works
       much better with Perl 5.8.1 and later, in(1,8) Perl 5.8.0 the settings were
       not quite right.

       This README was written by Sherm Pendley <>.  The
       "Starting From Scratch" recipe was contributed by John Montbriand

       Last modified 2003-09-08.

perl v5.8.5                       2004-04-23                     PERLMACOSX(1)

References for this manual (incoming links)