From: Sherm Pendley Date: Mon, 16 Jan 2006 16:53:23 +0000 (-0500) Subject: Re: [PATCH] Updated README.macosx X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=e30a8c0c6e0087de01552c4bf69ced9f4f2756db;p=p5sagit%2Fp5-mst-13.2.git Re: [PATCH] Updated README.macosx Message-Id: <619C9A5D-972F-4B90-A99A-B4B6D04C584D@dot-app.org> p4raw-id: //depot/perl@26877 --- diff --git a/README.macosx b/README.macosx index 04f8d10..c26eb0f 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), but the load time will be -significantly greater than either the static library, or Apple's +(S), 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, 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.) -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, which contain -code for both PowerPC and Intel architectures. (In the past, and on -other platforms, such executable files have been known as I.) 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 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) is a nice +way to extract the Perl binaries from the OS media, without having to +reinstall the entire OS. + =head1 AUTHOR