Common OS X problems

Posted by grahams on 2012-10-10 16:33
OS: OS X | Product: ActivePerl | tags: activeperl installation os x

ActivePerl isn't working on OS X. Why?


-Are you still getting the system version of Perl instead of ActivePerl?
You likely have not finished the installation. Read the Configuration step in the Installation Guide, which explains how to set $PATH so that ActivePerl is found ahead of the system version.
If you don't put ActivePerl on $PATH, then you must access ActivePerl and ppm using the full directory path, /usr/local/ActivePerl-5.16/bin/perl (or equivalent for other releases).

-I set $PATH yesterday, and I'm sure I had ActivePerl working, but today it's not working.
Changes to $PATH are volatile. You have to make the changes permanent by setting up your $PATH in your .profile shell configuration file.

-I can't do that. I don't have a .profile in my home directory.
No you don't. Apple designed OS X to use GUI interfaces, and they didn't think a config file for the command line shell would be necessary. You have to manually replicate what every other flavor of Unix does; copy /etc/profile to .profile in your home directory, and make changes to your personal copy.

-I did that, but it still isn't working.
You have to restart your shell before changes to .profile get read.

-Ok, I did all that, and Perl is working every time, but PPM won't add or remove modules.
You are a normal user. ActivePerl is installed into a directory which normal users can't write. PPM needs to be run through "sudo ppm" to give it the elevated privilege to manage modules.

-Huh? I wanted to replace the Apple Perl with ActivePerl. This process doesn't do that. How can I force ActivePerl to replace the Apple version?
Don't. Some of your system tools, and quite a few other vendor products expect to find a specific version of Perl in a specific place on a specific version of OS X. Replacing the Apple Perl will break things, and it is difficult to put things back without re-installing your operating system. Apple Perl will co-exist happily with ActivePerl if the defaults in the ActivePerl installer are used. Both versions will still be usable if you supply full paths to the command.

-Can't I just edit the system default /etc/profile to put ActivePerl on $PATH first? Won't that make it the default Perl?
Yes, it will, and so will creating symbolic links in system directories that are already high on the $PATH. Either of these approaches might still break third party software and system tools if they don't use hard-coded paths to the Apple Perl. On the positive side, making ActivePerl the default Perl in one of these ways is very simple to back out if for some reason things go pear shaped.

-I did everything above, but all I get is weird crashes when I run ActivePerl.
Do you have PERL5LIB set to point at the Apple Perl? Using PERL5LIB can force Perl to load libraries which contain incompatible binaries.

-I've got PPM working, but the module I want isn't available. I tried to build it locally from the CPAN source code, but I just can't seem to set the right compiler options.
ActivePerl binaries are multi-platform. Some releases were PPC/x86, and newer releases are x86/x86_64. When you compile a module locally, the compiler will only build a single architecture binary, and no matter which platform you are on, it won't match the dual architecture of the ActivePerl binaries unless you use the Apple SDK to convert what you build to match. Using the Apple SDK is a topic outside the scope of ActivePerl support.