Apple updates Xcode 4.4, seeds the first point release for Mountain Lion, and somehow manual symbolicating of crash reports has become broken.
Podcast: Download (17.5MB)
Show Notes
On August 7th Apple released version 4.4.1 of Xcode. Besides the already known 4.4 news the release notes are simply “This update runs on both OS X Lion and OS X Mountain Lion.”. There was an article by Apple Insider that claimed that 4.4.1 was the first release of Xcode as a standalone app, but apparently they deleted the article after realizing that this was BS. Though you still can find all the other blogs which simply copied some contents of the original content. I think I remember that Xcode 4.3 was the first version which replaced the installer app with an Xcode.app and moved some of the developer tools inside the app bundle.
Version 10.8.1 of Mountain Lion is not out to the public yet, but if you’re registered for the Mac developer program you have received an invite to the seed download invitation. There were rumors that this supposedly tweaks something about the graphics card to use less battery because people were claiming reduced battery endurance with 10.8. Though the seed notes do not mention this.
A user opened the distribution files in a tool called “Pacifist” and reports this:
Things of Note: Mail, QuickTime Player, kernel, AppleSmartBatteryManager (AHA!), 802.11, AHCI, and USB kexts, updates to system Mail components, Messages components, Bonjour.
Zimbra + Mountain Lion not being able to add calendar entries over CalDAV = Bug in Zimbra, Workaround is to set the default alert times. The problem occurs if the Calendar app tries to add an appointment with no alert set. Weird that this never occured before. In fact this was always working perfectly on my iOS devices. But ok, I set the default alerts and now the problem no longer occurs.
Several developers reported that they are no longer able to manually symbolicate crash reports with the Xcode 4.4 tools. We found this problem ourselves as well trying to symbolicate a crash report with a dSYM and app binary which had before generated on our Jenkins build server. There are two apparent workarounds, though I don’t understand how those are interrelated: Getting the atos start address, or hacking the symbolicate script. As I understand it then you can just look at the latter because the atos one only works if you have the debug symbols not stripped from the binary. The script fix is about helping mdfind which is used by the script to find the binary inside the .app bundle to actually find it. It might have to do with some people renaming the app bundle and dSYM after building to for example include the build number.
Categories: Podcast
