When building OpenSSL as a component build on OS X, by default export all symbols (matching Linux)

When building OpenSSL as a component build on OS X, by default export all symbols (matching Linux)

BUG=none
R=davidben@chromium.org

[Ryan Sleevi, 2014-05-01 00:48:47]

David: Easy fix for component builds
haavard: FYI. I suspect you've been doing your OS X testing with a static
library build, rather than component=shared - does that sound right?

[haavardm, 2014-05-01 07:27:41]

On 2014/05/01 00:48:47, Ryan Sleevi wrote:
> haavard: FYI. I suspect you've been doing your OS X testing with a static
> library build, rather than component=shared - does that sound right?

Yes, that seems correct. I have not seen this issue.

[davidben, 2014-05-01 16:14:52]

LGTM. I get a different compile failure now (OpenSSLPrivateKeyStore), but that
seems more expected since we don't have client auth glue yet.

[Ryan Sleevi, 2014-05-01 16:15:36]

The CQ bit was checked by rsleevi@chromium.org

[commit-bot: I haz the power, 2014-05-01 16:15:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rsleevi@chromium.org/263743004/1

[commit-bot: I haz the power, 2014-05-01 16:16:04]

Change committed as 267524

[haavardm, 2014-05-05 11:46:18]

On 2014/05/01 16:16:04, I haz the power (commit-bot) wrote:
> Change committed as 267524

David: I assume you mean this one?

"net::OpenSSLPrivateKeyStore::StoreKeyPair(GURL const&, evp_pkey_st*)",
referenced from:
    net::KeygenHandler::GenKeyAndSignChallenge() in net.keygen_handler_openssl.o
ld: symbol(s) not found for architecture i386

That compile error does not happen when doing static build, that's why I haven't
seen it. I believe the reason is that KeygenHandler::GenKeyAndSignChallenge() is
not actually used, and thus removed during optimization before linking when
doing static build.

I guess a short term fix would be to compile openssl_private_key_store_memory.cc
for OS X.