Broken /usr/bin/perl

[cmac]

On my home system under Mac OS X Leopard, I seem to have broken /usr/bin/perl for certain scripts. For example,

dual-1-25:~/.cpan/build $ perl -MCPAN -e "shell"
IO object version 1.22 does not match bootstrap parameter 1.23 at /Sys
+tem/Library/Perl/5.8.8/darwin-thread-multi-2level/XSLoader.pm line 97
Compilation failed in require at /System/Library/Perl/5.8.8/darwin-thr
+ead-multi-2level/IO/Handle.pm line 263.

The older version (presumably Apple original) in /usr/local/bin has no such problem. Both versions say they're 5.8.8. Also, /usr/bin/perl (which takes precedence over /usr/local/bin/perl) is suspiciously small at 47KB compared to 1203KB for /usr/local/bin/perl.

I don't remember what I did to get to this state. The date on /usr/bin/perl is in Jan of this year, so maybe I built it from source. Re-installing XSLoader and IO::Handle (from CPAN using /usr/local/bin/perl) did not help.

What would you do to fix this? Copy or link /usr/bin/perl* from /usr/local/bin? Install a newer version in /usr/bin? Does anyone know if I install a new Apple XTools package, will it create new /usr/bin/perl*?

Thanks,
cmac

[moritz]

Also, /usr/bin/perl (which takes precedence over /usr/local/bin/perl) is suspiciously small at 47KB compared to 1203KB for /usr/local/bin/perl.

That's not a problem if it dynamically links to libperl.so. It's 6.8k on my system and works fine.

What would you do to fix this?

Remove all parts of the perl in /usr/local/, and reinstall the one in /usr/bin.

Update: I don't know the package management system that comes with MacOS, but I guess it'll replace /usr/bin/perl. And a small advice for the future: /usr/ is reserved for things come are installed via the package manager; for things compiled from source there's /usr/local/ or /opt/.

[graff]

I had a problem of a similar nature, maybe not affecting perl itself, but making enough of a mess in my module library that perl was seriously disabled.

TimeMachine to the rescue. I had learned (the hard way, after a real disk crash) that this now-standard utility is a Really Good Thing -- it works. So my external/removable TimeMachine drive had the pre-corruption version of the module library directory tree, and things were back to normal with hardly any fuss.

You have been using TimeMachine, haven't you? Deleting your current foobar perl and restoring a pre-foobar version from backup is quick work (and especially effective, if you don't know what went wrong, but you do know roughly when it went wrong). The tool lets you browse older versions of relevant paths before restoring, to get a better idea of what you did and what you need to do to fix it.

[shmem]

The older version (presumably Apple original) in /usr/local/bin has no such problem.

Uh. Multiple screw up here. Local overrides reside in /usr/local, the shipped stuff should be in /usr as moritz pointed out. On any sane system, /usr/local/bin comes first in $PATH overriding /usr/bin. You might want to file a bug report against Apple for that.

As a quick fix, check your preferred perl's include path via perl -V. If your system's stuff (/usr/local/...) comes first, recompile adjusting the search path. You could also try adding a LD_LIBRARY_PATH variable (similar to $PATH) to your profile containing the correct directories in which the correct shared objects are residing, and, to use the correct modules for your preferred perl, a $PERL5LIB setting (see perlrun).

[telemachus]

Uh. Multiple screw up here. Local overrides reside in /usr/local, the shipped stuff should be in /usr as moritz pointed out. On any sane system, /usr/local/bin comes first in $PATH overriding /usr/bin. You might want to file a bug report against Apple for that.

Well, as far as that goes, OS X is not sane. The default $PATH looks like this:

/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

One of the first things I do on a new OS X system is adjust that to put /usr/local earlier. (I would also be shocked if filing a bug at Apple did squat. OS X is not built for developers who want to install software they compile themselves. The system has no compiler unless you install the extra, optional X Code tools.)

@Moritz: OS X doesn't really come with any package installer, if by 'package installer' you mean something like apt-get or yum. If you remove (or muck with) the system's Perl, I don't think it would be especially easy to fix that.

@Cmac: I think that you have it backwards. The built-in, Apple-provided Perl lives in /usr/bin. The custom one that you (or someone else) built or installed later should be in /usr/local. So the Perl that is messed up is apparently Apple's. There are some tips here about how you might try to reinstall up the system-wide Perl if you've tampered with it. But the author describes it as "much like conducting brain surgery to yourself. Without anesthesia." So, that's a last resort apparently. Try to remove the stuff in /usr/local first. It should be easy enough to recompile that on your own, if you decide that you want it back. I hope this helps.

Edit: to answer your question, you can't reinstall Perl simply by reinstalling X Code. Perl is part of the base installation packages. And you can't normally get at the individual items separately. The program Pacifist, available here, can apparently extract individual items, but I've never tried it. So I can't say one way or another how easy it is to use, how cleanly it works (or not), etc.

[pemungkah]

You didn't break it - Apple did. See http://bulknews.typepad.com/blog/2009/02/mac-os-x-security-update-2009001-breaks-perl-cpan.html - Apple brought back bad versions of some of the XS code (for IO, Scalar::Util, and Storable).

You'll need to hand-download and install those modules over again to fix it - download from CPAN, untar, cd in, perl Makefile.PL, make, make test, sudo make install for all three.

Other notes: never replace the system binary Perl - system updates may undo your work at any time. Always build your own somewhere else; if you use MacPorts, it will build in /opt/local for you.