Commit | Line | Data |
9ff7b177 |
1 | If you read this file _as_is_, just ignore the funny characters you see. |
2 | It is written in the POD format (see pod/perlpod.pod) which is specially |
3 | designed to be readable as is. |
4 | |
5 | =head1 NAME |
6 | |
7 | README.macosx - Perl under Mac OS X |
8 | |
9 | =head1 SYNOPSIS |
10 | |
11 | This document briefly describes perl under Mac OS X. |
12 | |
13 | |
14 | =head1 DESCRIPTION |
15 | |
16 | The latest Perl (5.8.1-RC3 as of this writing) builds without changes |
17 | under Mac OS X. Under the 10.3 "Panther" release, all self-tests pass, |
18 | and all standard features are supported. |
19 | |
20 | Earlier Mac OS X releases did not include a completely thread-safe libc, |
21 | so threading is not fully supported. Also, earlier releases included a |
22 | somewhat buggy libdb, so some of the DB_File tests are known to fail on |
23 | those releases. |
24 | |
25 | |
26 | =head1 INSTALLATION PREFIX |
27 | |
28 | The default installation location for this release uses the traditional |
29 | UNIX directory layout under /usr/local. This is the recommended location |
30 | for most users, and will leave the Apple-supplied Perl and its modules |
31 | undisturbed. |
32 | |
33 | Using an installation prefix of '/usr' will result in a directory layout |
34 | that mirrors that of Apple's default Perl, with core modules stored in |
35 | '/System/Library/Perl/${version}', CPAN modules stored in |
36 | '/Library/Perl/${version}', and the addition of |
37 | '/Network/Library/Perl/${version}' to @INC for modules that are stored |
38 | on a file server and used by many Macs. |
39 | |
40 | |
41 | =head1 LIBPERL AND PREBINDING |
42 | |
43 | Mac OS X ships with a dynamically-loaded libperl, but the default for |
44 | this release is to compile a static libperl. The reason for this is |
45 | pre-binding. Dynamic libraries can be pre-bound to a specific address in |
46 | memory in order to decrease load time. To do this, one needs to be aware |
47 | of the location and size of all previously-loaded libraries. Apple |
48 | collects this information as part of their overall OS build process, and |
49 | thus has easy access to it when building Perl, but ordinary users would |
50 | need to go to a great deal of effort to obtain the information needed |
51 | for pre-binding. |
52 | |
53 | You can override the default and build a shared libperl if you wish, but |
54 | the load time will be significantly greater than either the static |
55 | library, or Apple's pre-bound dynamic library. |
56 | |
57 | |
58 | =head1 UPDATING PANTHER |
59 | |
60 | As of this writing, the latest Perl release that has been tested and |
61 | approved for inclusion in the 10.3 "Panther" release of Mac OS X is |
62 | 5.8.1 RC3. It is currently unknown whether the final 5.8.1 release will |
63 | be made in time to be tested and included with Panther. |
64 | |
65 | If the final release of Perl 5.8.1 is not made in time to be included |
66 | with Panther, it is recommended that you wait for an official Apple |
67 | update to the OS, rather than attempting to update it yourself. In most |
68 | cases, if you need a newer Perl, it is preferable to install it in some |
69 | other location, such as /usr/local or /opt, rather than overwriting the |
70 | system Perl. |
71 | |
72 | If you find that you do need to update the system Perl, there is one |
73 | potential issue. If you upgrade using the default static libperl, you |
74 | will find that the dynamic libperl supplied by Apple will not be |
75 | deleted. If both libraries are present when an application that links |
76 | against libperl is built, ld will link against the dynamic library by |
77 | default. So, if you need to replace Apple's dynamic libperl with a |
78 | static libperl, you need to be sure to delete the older dynamic library |
79 | after you've installed the update. |
80 | |
81 | Note that this is only an issue when updating from an older build of the |
82 | same Perl version. If you're updating from (for example) 5.8.1 to 5.8.2, |
83 | this issue won't affect you. |
84 | |
85 | |
86 | =head1 MACPERL |
87 | |
88 | Quite a bit has been written about MacPerl, the Perl distribution for |
89 | "Classic MacOS" - that is, versions 9 and earlier of MacOS. Because it |
90 | runs in environment that's very different from that of UNIX, many things |
91 | are done differently in MacPerl. Modules are installed using a different |
92 | procedure, Perl itself is built differently, path names are different, |
93 | etc. |
94 | |
95 | From the perspective of a Perl programmer, Mac OS X is more like a |
96 | traditional UNIX than Classic MacOS. If you find documentation that |
97 | refers to a special procedure that's needed for MacOS that's drastically |
98 | different from the instructions provided for UNIX, the MacOS |
99 | instructions are quite often intended for MacPerl on Classic MacOS. In |
100 | that case, the correct procedure on Mac OS X is usually to follow the |
101 | UNIX instructions, rather than the MacPerl instructions. |
102 | |
103 | |
104 | =head1 CARBON |
105 | |
106 | MacPerl ships with a number of modules that are used to access the |
107 | classic MacOS toolbox. Many of these modules have been updated to use |
108 | Mac OS X's newer "Carbon" toolbox, and are available from CPAN in the |
109 | "Mac::Carbon" module. |
110 | |
111 | |
112 | =head1 COCOA |
113 | |
114 | There are two ways to use Cocoa from Perl. Apple's PerlObjCBridge |
115 | module, included with Mac OS X, can be used by standalone scripts to |
116 | access Foundation (i.e. non-GUI) classes and objects. |
117 | |
118 | An alternative is CamelBones, a framework that allows access to both |
119 | Foundation and AppKit classes and objects, so that full GUI applications |
120 | can be built in Perl. CamelBones can be found on SourceForge, at |
121 | L<http://www.sourceforge.net/projects/camelbones/>. |
122 | |
123 | |
124 | =head1 AUTHOR |
125 | |
126 | This README was written by Sherm Pendley E<lt>sherm@dot-app.orgE<gt>. |
127 | |
128 | =head1 DATE |
129 | |
130 | Last modified 2003.07.31. |