Anyway, after plenty of frustration, I noticed some chatter about the damn thing being busted in Xcode 4. Figures!

There’s an alternate third party version on GitHub, but this didn’t really help me – I still got inscrutable errors, so I took a look at the original.

The version that comes with Xcode 4 appears to have some problems distinguishing, say, an iPhone Simulator build of the app from a native build sitting in the Archives folder. I’d just see an error about otool and some binary living in the iPhone Simulator folder.

Digging into the errant symbolicatecrash source, I noticed that the code that finds the executable path tests each candidate using otool, but doesn’t seem to be able to comprehend the output from otool caused by running it on the wrong architecture.

So, replacing the rather unhelpful ‘die’ statement on line 323:

die "Can't understand the output from otool ($TEST_uuid -> '$otool -arch $arch -l $path')";

With a “No, it ain’t this executable” response:

return 0;

…solves the problem immediately. Now I can drag crash logs straight into the Organizer in Xcode, and it’ll symbolicate correctly.

I came across a great XCode project wrapper for OpenSSL yesterday, by Stephen Lombardo. This is an XCode project file that contains a target to build OpenSSL from source, and works with both Mac and iOS projects. I made some modifications to it, in order to make it work by just dropping in the OpenSSL source tarball, without having to dirty up your source tree with the extracted OpenSSL distribution.

Here’s how to use it:

1. Download the OpenSSL source.
2. Put the downloaded OpenSSL source tar.gz into the same folder as openssl.xcodeproj (I put it in Library/openssl within my project tree).
3. Drag the openssl.xcodeproj file into your main project tree in XCode.
4. Right-click on your project target, and add openssl.xcodeproj under “Direct Dependencies” on the General tab.

5. On the Build tab for your project’s target, find the “Header Search Paths” option, and add the path:

   $(SRCROOT)/Library/openssl/build/openssl.build/openssl/include

   (Assuming you’ve put openssl.xcodeproj at the path Library/openssl — adjust as necessary).

6. Expand your target’s “Link Binary With Libraries” build stage, and drag libcrypto.a from the openssl.xcodeproj group.

Then, you can just import and use as normal (#import <openssl/dsa.h>, etc).

Download it here

I just got coverage working too, thanks to a useful article at SuperMegaUltraGroovy on how to use code coverage with XCode. There were a couple of caveats that I thought I’d share, though.So, to repeat SMUG’s instructions:

1. Set up unit testing
2. Create a new build configuration (‘Coverage’), duplicated from the ‘Debug’ configuration
3. Open up build settings for the main target, make sure your new configuration is selected, and:
   • Enable “Generate Test Coverage Files”
   • Enable “Instrument Program Flow”
   • Add “-lgcov” to “Other Linker Flags”

SMUG proposes some commands to append to the “Run Script” build phase of the unit test target, in order to generate the coverage report and output a summary to the build results (see the original article). I made some modifications to aid readability. So, instead, I added the following to the “Run Script” phase of the unit test target:

# Run gcov on the framework getting tested
if [ "${CONFIGURATION}" = 'Coverage' ]; then
     TARGET_NAME="My Application"
     OBJ_DIR=${OBJROOT}/${TARGET_NAME}.build/${CONFIGURATION}/${TARGET_NAME}.build/Objects-normal/${CURRENT_ARCH}
     mkdir -p Coverage
     pushd Coverage
     find "${OBJROOT}" -name *.gcda -exec gcov -o "${OBJ_DIR}" {} \; 2>/tmp/gconv-stderr | egrep "^File|^Lines" | sed -E "s@File '$SRCROOT/@@;s@(\.[a-zA-Z])'@\1: @;s@Lines executed:([0-9.%]+) of ([0-9]+)@\1 (\2)@" | paste -d" " - - | egrep -v "^File '" | sed -E "s@^([^:]+):([^(]*)(\([^)]+\))@\2:\1\3@" | sort -n | sed -E "s@^([^:]+):([^(]*)(\([^)]+\))@\2:\1\3@"; cat /tmp/gconv-stderr | grep -v "version.*, prefer.*"; rm /tmp/gconv-stderr
     popd
fi

This orders the results by coverage percentage, reformats the output to be a bit terser and more readable, and suppresses some unnecessary warnings about GCC 4.0 (see below).

Finally, using XCode 3.2 on Snow Leopard (Mac OS X 10.6), I found that there were a few issues. Using any SDK other than 10.6 results in build errors:

“vproc_transaction_begin”, referenced from:
__gcov_init in libgcov.a(_gcov.o)
_vproc_transaction_begin$non_lazy_ptr in libgcov.a(_gcov.o)
“_vproc_transaction_end”, referenced from:
_gcov_exit in libgcov.a(_gcov.o)
_vproc_transaction_end$non_lazy_ptr in libgcov.a(_gcov.o)
ld: symbol(s) not found

The solution I found in the Apple lists archives is to use the same SDK as the OS: 10.6 (Project menu, Set Active SDK, 10.6).

After fixing this, I was getting dubious-looking results – mostly 0.00% code coverage except for a few random files. The suggestion for this was to use GCC 4.0 instead of the default 4.2 (edit build settings for the main target, and probably the unit test target too, and select “GCC 4.0″ under “C/C++ Compiler Version”).

After a clean and rebuild, I’m getting proper results.

Phew.

• TinEye Reverse Image Search TinEye is a reverse image search engine. You can submit an image to TinEye to find out where it came from, how it is being used, if modified versions of the image exist, or to find higher resolution versions.
• Traffic Shaping in Mac OS X | Mac Geekery "…Create several pipes that have a set bandwidth and other properties for all packets that get filed into them; you then add queues to those pipes that determine what priority certain requests will get in that pipe; then you add actual firewall rules to identify packets and file them into queues."
• Brandon Walkin » Introducing BWToolkit BWToolkit is a BSD licensed plugin for Interface Builder 3 that contains commonly used UI elements and other useful objects. Using these objects is as simple as dragging them from the library to your canvas or document window. In particular, "No Code" preferences window and tabbed sheets.
• Aussie iPhone app developers and the IRS? Discussion about tax details for Australian iPhone developers. It appears the advice from Apple on the tax form is incorrect for sales on the App Store.
• google-toolbox-for-mac – How to do iPhone unit testing This is a quick tutorial on doing iPhone unit testing using the facilities in the Google Toolbox For Mac