Wean Mac Breakpad off of its OpenSSL libcrypto dependency

Wean Mac Breakpad off of its OpenSSL libcrypto dependency.

This libcrypto dependency sucks. Linking against OpenSSL is sort of broken in
certain Mac OS X SDKs. libcrypto was only being used to provide an MD5
implementation. Breakpad already has its own MD5 implementation, so just use
that instead.

To be perfectly honest, on modern systems, nothing should be making MD5
hashes of modules anyway, because everything has an embedded LC_UUID.

The project file changes just remove libcrypto and add md5.c as needed.

A bonus (and untested) fix for on_demand_symbol_supplier.mm is included to
account for changes in r794.

r819

[Ted Mielczarek]

You know, we've actually had part of this patch downstream in Mozilla for a
while, I was just lax in upstreaming it:
http://breakpad.appspot.com/229001

We hit problems building a 10.5/i386 binary on 10.6, it was linking to our NSS
symbols instead of libcrypto. I wanted to try to find the root cause, but I
guess I never got around to it!

[Ted Mielczarek]

LGTM

http://breakpad.appspot.com/296001/diff/3001/14
File src/tools/mac/crash_report/on_demand_symbol_supplier.mm (right):

http://breakpad.appspot.com/296001/diff/3001/14#newcode296
Line 296: dump.WriteSymbolFile(file);
Oops, sorry I missed that in my bustage fix patch.

[Mark Mentovai]

ted.mielczarek@gmail.com wrote:
> You know, we've actually had part of this patch downstream in Mozilla
> for a while, I was just lax in upstreaming it:
> http://breakpad.appspot.com/229001
>
> We hit problems building a 10.5/i386 binary on 10.6, it was linking to
> our NSS symbols instead of libcrypto. I wanted to try to find the root
> cause, but I guess I never got around to it!

The root cause is that the OpenSSL libraries in the 10.6 SDK at
/usr/lib/libssl.dylib and /usr/lib/libcrypto.dylib have LC_ID_DYLIB load
commands identifying them as /usr/lib/libssl.0.9.8.dylib
/usr/lib/libcrypto.0.9.8.dylib. This means that ld will use these libraries for
-lssl and -lcrypto (which is how people link against OpenSSL) and the linker
output will contain LC_LOAD_DYLIB commands pointing to the paths that have those
version numbers in them. On Mac OS X 10.5, nothing exists at those paths. The
0.9.7 variants are loadable on both 10.5 and 10.6, but 0.9.8 began in 10.6 only.

This is a bug in the SDK, although it‘s a limitation of the way the SDK system
works. Apple normally doesn’t version libraries in this way, but the OpenSSL
libraries are exceptions.

I’ve been aware of this problem for about two years, and I think I even reported
it to Apple and had it duped against some other bug. I spotted it being called
out in a recent Xcode release note document.

As of 10.7, the OpenSSL libraries are marked as deprecated. The system has
enough crypto support elsewhere anyway.

[Ted Mielczarek]

Interesting. I'm pretty sure we're linking against the 10.5 SDK building our
i386 builds on 10.6, but maybe we're doing something wrong. Either way, this is
the right thing to do.