I have now uninstalled and re-installed XCode-312 three times, both by running the uninstaller and by just deleting /Deveoper/ and every time I run the installer it tells me it's doing an "upgrade" and fails to install diagnostics.pm (wherever that's supposed to go) and also doesn't create links for, e.g., /usr/bin/gcc (though gcc is in /Developer/usr/bin/).
So how do I un-screw things?
(And, hey, Apple -- "genius" idea not to ship diagnostics.pm in the standard, non-XCode Perl install.)
Update: I gave up and installed the newer XCode. It's so frustrating that I have to wait for a 4.7 GB download just to have a functional gcc and perl... I will never run XCode on this machine (let alone the iPhone cross-compiler!), but there's no other way to get the parts that everything else depends on.
Maybe just go with installing CPAN to get diagnostics, or manually place diagnostics.pm in your @INC path?
diagnostics.pm lives in /System/Library/Perl/5.x.x/
This file is actually packaged in com.apple.pkg.Essentials. It's not possible to install the OS and not get a copy of this file. My guess is that perhaps the Perl interpreter you're using is not the one installed by default.
For the Xcode problem, I'm not sure why it's doing an upgrade. Perhaps nuke the receipt in /Library/Receipts? I'd have to dig around to find how it decides to upgrade and not install. In any case, that will only help the symlink problem, not the Perl problem.
Also I'm stale on my Perl, but perhaps your home directory contains some dot file turd that is pointing Perl to the wrong library path? Just a thought.
No, I am 100% certain that if you have a vanilla 10.6 install, without XCode, then the system Perl in /usr/bin/ dies if a script does "use diagnostics;". This has been true for many years, possibly forever.
I had to remove "use diagnostics" from all of the Perl scripts included with xscreensaver to make it work for the majority of users out in the real world. Anyone without XCode had failures.
Possibly it's perldiag.pod that's missing, not diagnostics.pm -- but the reality is that Apple ships a Perl that croaks if you do "use diagnostics" and don't have XCode installed.
I think I see the issue. Stay tuned, we'll be back after these important messages …
So after some scrounging with pkgutil, I find that "perldiag.pod" lives in /System/Library/Perl/5.x/pods/perldiag.pod which appears to be installed by DevSDK.pkg from Xcode.
Saddle up the Xcode dmg and try:
sudo /usr/sbin/installer -verbose -pkg /Volumes/Xcode/Packages/DevSDK.pkg -target /
See if that works.
Sweet. I "love" it when SDKs install their libraries into the system runtime libraries (especially into interpreters, where the errors get pushed to script execution time).
And the issue was brought up and responded to by an Apple employee on perl5-porters back in November 2004, who said it might get fixed... in Tiger. Keep hoping!
One thing to note. Definitely report this as a bug. Even if it exists previously. Use your mozilla cred if you need to.
-Dan
I've had no luck reporting bugs to Apple through official channels, so I've pretty much stopped trying. It has been a hundred times more effective to just bitch here and hope that some relevant employee sees it.
Well, there is *that* mozilla cred as well :)
Does that help anymore? It seems to me it's been a few years since filing things with apple's bugradar thing has done me any good.
IIRC, the version of Xcode that shipped with 10.6.x is 3.2. Is it possible that the older 3.1 branch doesn't put things in the right spot?
Xode version here on 10.6.7 is 3.3.2, though the Xcode app itself claims it's 3.2.6 (1761).
Apple pulled Xcode 3.3 from its developer site after making Xcode 4.0 available for $5 through the app store, though 3.3 may be available elsewhere. Either way, running an Xcode older than the OS version is... not recommended.
There's definitely an xcode 3.x still on the apple site. We have an educational institution developer's license and it won't let us download 4, but offers us 3. Frustratingly.
Does this mean that in the future I'll have to spend $5 more to get gcc on OSX?
diags is old (1995) and sort of a joke. yes, do remove it from scripts.
It provides useful error messages. You are full of shit.
Or, just a thought, you could just keep using that fine module.
As you say, diagnostics.pm should be part of the standard Perl deployment so something is clearly amiss.
Diagnostics pulls out bits from perldiag.pod, which is clever. It does not appear to find different problems than strict and warnings, both of which have worked well for me over the years.
Joe,
I'm unclear on your reply. If diagnostics does not appear to find different problems than strict and warnings, and was never part of the standard perl deployment, why should this redundant functionality be added in to the standard perl deployment?
Lloyd,
I think my sloppy writing led to some confusion. I believe diagnostic.pm has been part of the standard Perl distribution for some time. What I meant was simply "JWZ, you have indeed found a problem with the Apple distro of Perl."
The diagnostic module was written by the (im)famous Tom Christiansen, who contributed quite a lot to Perl for many, many years. The module amplifies warnings and errors that the perl interpreter issues by combing through perldiag.pod. This can be of great help to new and casual Perl programmers.
At a high level, I was merely suggesting that diagnostics should not be a critical module for production or deployed code. As the lack of this module appears to be causing JWZ grief, I thought I might add my two cents worth of software consulting to this discussion. As you can see,
he does not agree with my estimation of diagnostics' value -- but reasonable people may disagree about such things.
I guess it means your youtubedown cannot be used on OS X 10.6.7 until you find a fix ;-(
Install XCode, or comment out the use diagnostics line, I guess...
Why in the world are you using the vendor copy of Perl? You are just asking for problems. Take a look at App::perlbrew for a sensible way of getting and managing perl. This also means you are not stuck with 5.10.0 (which is getting a bit long in the tooth). You may also want to look into App::cpanminus.
Perl has not changed in any significant way in fifteen years -- which is most of why I use it at all: it is a mature language, unlike the other moving-target senior projects out there that the kids like today -- so why would I give a flying fuck what version it is?
Also, when I'm distributing software for normal, non-developer users to run, and this software just happens to be written partly in Perl, do you think I want to tell them that they have to install XCode, or MacPorts, or CPAN first, or that I should include an Entire copy of Perl inside the screen saver? I guess you do think that.
So, yeah, when someone asks, "why would you use the vendor-supplied Perl", what I hear is, "hurf durf I eat paste."
Bullshit, Perl has changed significantly over the last fifteen years. It has just retained backwards compatibility. Here is a small list of changes:
our variables (lexically scoped names for package variables)
File and directory handles can be autovivified (e.g. open my $fh, "<", $filename or die $!)
Weak references (which allow the GC to handle cyclic structures)
A ton of changes in how Unicode is supported
How threading works
What \d and \w mean in regexes (if you think they mean [0-9] and [a-zA-Z0-9_] you are gravely mistaken after 5.8)
The PerlIO layer
Restricted hashes
Attributes for functions
given/when switch statement
state variables
the defined-or operator (e.g. $foo //= 5 is equivalent to $foo = defined $foo ? $foo : 5)
the smart-match operator
named captures in regexes
And that barely touches the changes.
As for how to make sure you have a sane version of Perl, yes, you must bundle a copy of it with your software. Take a look at what VMWare does. Vendor copies of Perl are notoriously screwed up. I have never understood why vendors insist on screwing it up, but they do. And you are running into a problem for this very reason.
Even if Apple decides to fix this problem for you in a new release, you still have to deal with all of the machines that still have the broken version.
In the mean time, just say
BEGIN { eval "use diagnostics" or eval "use warnings" or die $@ }
This will get you the diagnostics pragma if it is available, the warnings pragma if it isn't, or die if the warnings pragma can't be found.