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.
Using an installation prefix of '/usr' will result in a directory layout that mirrors that of Apple's default Perl, with core modules stored in '/System/Library/Perl/${version}', CPAN modules stored in '/Library/Perl/${version}', and the addition of '/Network/Library/Perl/${version}' to @INC for modules that are stored on a file server and used by many Macs.
You can override the default and build a shared libperl if you wish (Configure ... -Duseshrlib), but the load time will be significantly greater than either the static library, or Apple's pre-bound dynamic library.
If the final release of Perl 5.8.1 is not made in time to be included with Panther, it is recommended that you wait for an official Apple update to the OS, rather than attempting to update it yourself. 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.1 to 5.8.2, this issue won't affect you.
Configure ... -Uloclibpth -Dlibpth=/usr/lib
to make Configure look 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 pre-Panther systems), add those to the libpth:
Configure ... -Uloclibpth -Dlibpth='/usr/lib /opt/lib'
The default of building Perl statically may cause problems with complex applications like Tk: in that case consider building shared Perl
Configure ... -Duseshrplib
but remember that there's a startup cost to pay in that case (see above ``libperl and Prebinding'').
From the perspective of a Perl programmer, Mac OS X is more like a traditional UNIX than Classic MacOS. If you find documentation that refers to a special procedure that's needed for MacOS that's drastically different 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.
An alternative is CamelBones, a framework that allows access to both Foundation and AppKit classes and objects, so that full GUI applications can be built in Perl. CamelBones can be found on SourceForge, at <http://www.sourceforge.net/projects/camelbones/>.
First, get rid of the libperl.dylib:
# cd /System/Library/Perl/darwin/CORE
# rm libperl.dylib
Then delete every .bundle file found anywhere in the folders:
/System/Library/Perl
/Library/Perl
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 -Dusershrplib" NOTE: the "-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.