Re: [PATCH] Updated README.macosx

Message-Id: <619C9A5D-972F-4B90-A99A-B4B6D04C584D@dot-app.org>

p4raw-id: //depot/perl@26877

1 files changed, 67 insertions, 58 deletions

diff --git a/README.macosx b/README.macosx
index 04f8d10730..c26eb0f8e6 100644
--- a/README.macosx
+++ b/README.macosx
@@ -13,15 +13,14 @@ This document briefly describes perl under Mac OS X.
 
 =head1 DESCRIPTION
 
-The latest Perl (5.8.8 as of this writing) builds without changes
-under Mac OS X. Under the 10.4 "Tiger" release, all self-tests pass,
-and all standard features are supported.
+The latest Perl release (5.8.8 as of this writing) builds without changes
+under Mac OS X. Under 10.3 "Panther" and newer OS versions, all self-tests
+pass, and all standard features are supported.
 
-Mac OS X releases prior to 10.3 "Panther" did not include a completely
-thread-safe libc, so threading is not fully supported when Perl is built
-for these releases. Also, earlier releases included a
-somewhat buggy libdb, so some of the DB_File tests are known to fail on
-those releases.
+Earlier Mac OS X releases (10.2 "Jaguar" and older) did not include a
+completely thread-safe libc, so threading is not fully supported. Also,
+earlier releases included a buggy libdb, so some of the DB_File tests
+are known to fail on those releases.
 
 
 =head2 Installation Prefix
@@ -39,6 +38,43 @@ that mirrors that of Apple's default Perl, with core modules stored in
 on a file server and used by many Macs.
 
 
+=head2 SDK support
+
+First, export the path to the SDK into the build environment:
+
+    export SDK=/Developer/SDKs/MacOSX10.3.9.sdk
+
+Use an SDK by exporting some additions to Perl's 'ccflags' and '..flags'
+config variables:
+
+    ./Configure -Accflags="-nostdinc -B$SDK/usr/include/gcc \
+                           -B$SDK/usr/lib/gcc -isystem$SDK/usr/include \
+                           -F$SDK/System/Library/Frameworks" \
+                -Aldflags="-Wl,-syslibroot,$SDK" \
+                -de
+
+=head2 Universal Binary support
+
+To compile perl as a universal binary (built for both ppc and intel), export
+the SDK variable as above, selecting the 10.4u SDK:
+
+    export SDK=/Developer/SDKs/MacOSX10.4u.sdk
+
+In addition to the compiler flags used to select the SDK, also add the flags
+for creating a universal binary:
+
+    ./Configure -Accflags="-arch i686 -arch ppc -nostdinc -B$SDK/usr/include/gcc \
+                           -B$SDK/usr/lib/gcc -isystem$SDK/usr/include \
+                           -F$SDK/System/Library/Frameworks" \
+                -Aldflags="-arch i686 -arch ppc -Wl,-syslibroot,$SDK" \
+                -de
+
+Keep in mind that these compiler and linker settings will also be used when
+building CPAN modules. For XS modules to be compiled as a universal binary, any
+libraries it links to must also be universal binaries. The system libraries that
+Apple includes with the 10.4u SDK are all universal, but user-installed libraries
+may need to be re-installed as universal binaries.
+
 =head2 libperl and Prebinding
 
 Mac OS X ships with a dynamically-loaded libperl, but the default for
@@ -52,62 +88,31 @@ 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 you wish
-(S<Configure ... -Duseshrlib>), but the load time will be
-significantly greater than either the static library, or Apple's
+(S<Configure ... -Duseshrlib>), but the load time on pre-10.4 OS
+releases will be greater than either the static library, or Apple's
 pre-bound dynamic library.
 
+With 10.4 "Tiger" and newer, Apple has all but eliminated the performance
+penalty for non-prebound libraries.
 
-=head2 Updating Apple-supplied Perl
-
-Apple ships a threaded build of perl 5.8.6 with Mac OS 10.4.x, "Tiger".
-In most cases, if you need a newer Perl, it is preferable to install it in some
-other location, such as /usr/local or /opt, rather than overwriting the
-system Perl.  The default location (no -Dprefix=... specified when running
-Configure) is /usr/local.
-
-If you find that you do need to update 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 will link against the dynamic library by
-default. So, if 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.6 to 5.8.8,
-this issue won't affect you.
 
-=head2 64-bit Perl
+=head2 Updating Apple's Perl
 
-By default, perl is built to use 32-bit integers and pointers. The hints file,
-F<hints/darwin.sh>, provides experimental support for 64-bit integers 
-and pointers (on G5 processors only) when Configure is run with the
-C<-Duse64bitall> option. Expect many compiler warnings and a number
-of test failures.
+In a word - don't, at least without a *very* good reason. Your scripts
+can just as easily begin with "#!/usr/local/bin/perl" as with
+"#!/usr/bin/perl". Scripts supplied by Apple and other third parties as
+part of installation packages and such have generally only been tested
+with the /usr/bin/perl that's installed by Apple.
 
-=head2 Intel processor support
+If you find that you do need to update the system Perl, one issue worth
+keeping in mind is the question of static vs. dynamic libraries. 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 will
+link against the dynamic library by default. So, if 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.
 
-At the time of writing, the Perl developers have no knowledge of the
-behaviour (or misbehaviour) of the Perl build process when hosted by
-an Intel-based Macintosh. As far as we know, Apple ships Perl 5.8.6
-with Intel developer builds of Mac OS X, so we presume that there
-are few or no problems in building that version of Perl. (The source
-package used by Apple may be found at L<http://opendarwin.org/>.)
-If you encounter problems in building a later version of Perl for an
-Intel-based Macintosh, please file a bug report, if possible by using
-the following command in the build directory: 
-
-    ./perl -Ilib utils/perlbug
-
-=head2  Universal binaries
-
-Apple's Xcode development tools, version 2.1 and later, provide
-support for the creation of I<universal binaries>, which contain
-code for both PowerPC and Intel architectures. (In the past, and on
-other platforms, such executable files have been known as I<fat
-binaries>.) Perl's build process currently provides no support for
-the production of universal binaries.
 
 =head2 Known problems
 
@@ -204,13 +209,17 @@ 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
+After this you can either copy Perl from your operating system media
 (you will need at least the /System/Library/Perl and /usr/bin/perl),
 or rebuild Perl from the source code with C<Configure -Dprefix=/usr
 -Dusershrplib> NOTE: the C<-Dprefix=/usr> to replace the system Perl
 works much better with Perl 5.8.1 and later, in Perl 5.8.0 the
 settings were not quite right.
 
+"Pacifist" from CharlesSoft (L<http://www.charlessoft.com/>) is a nice
+way to extract the Perl binaries from the OS media, without having to
+reinstall the entire OS.
+
 
 =head1 AUTHOR