Fix linking against new libssh2 formula

[robrix]

🚨 ⚠️ Warning: This is not ready to merge until we have confirmation that it doesn’t break the build for folks who haven’t updated brew yet, and that it actually works correctly in deployed projects linking against ObjectiveGit.framework. 🚨 ⚠️

This is intended to fix linking Objective-Git against the libssh2 that brew gives us, which apparently can no longer be linked against system openssl.

• confirm that it succeeds for @raheelahmad & @jlalvarez18
• confirm that it succeeds for someone who hasn’t done brew upgrade libssh2 to get 1.4.3_1 yet
• confirm that it is not linking the dylibs under /usr/local/… (and therefore that it can run on Macs without brew 😬) Unfortunately, we are.
• support other versions of openssl (is this sane?) Probably not sane to try to manage upstream’s versioning carefully. Totally sane, just change the library search path to /usr/local/opt/openssl/lib like brew told me to
• figure out how to make it prefer libssl.a and libcrypto.a to their dylib counterparts
• and then do that

Fixes #352.

[robrix]

@raheelahmad @jlalvarez18 Could you please give this branch a try?

[raheelahmad]

@robrix it does, but I had to modify your modified LIBRARY_SEARCH_PATHS to /usr/local/Cellar/openssl/1.0.1f/lib/ from /usr/local/Cellar/openssl/1.0.1g/lib/. (Not sure how ...f vs. ...g directories come about) .

[robrix]

I bet if you were to brew upgrade openssl you’d get g. Good to know tho—I’ll have to add that to the PR.

[raheelahmad]

Indeed. A brew update && brew upgrade openssl gave me the g.

[jlalvarez18]

Doing a brew update && brew upgrade openssl definitely fixes the problem. :) The branch looks good. Just a heads up... there is this warning

warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: -dynamic not specified, -all_load invalid
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: -dynamic not specified the following flags are invalid: -ObjC 

[robrix]

Thanks to you both!

@jlalvarez18: That warning is benign. We’re passing -all_load and -ObjC for the linker on a static archive, probably, and not on the thing linking it; but it doesn’t result in bad behaviour. Xcode 5.1 just changed the chattiness of libtool, is all.

[jlalvarez18]

@robrix no no.. thank you!

[robrix]

Okay, we are linking the dylibs:

/usr/local/Cellar/openssl/1.0.1g/lib/libcrypto.1.0.0.dylib
/usr/local/Cellar/openssl/1.0.1g/lib/libssl.1.0.0.dylib

So, that’s pretty terrible.

Going to go spelunking in the man pages to try to figure out what to do about this.

[jspahrsummers]

Including the path to the .a manually in the linker flags will link it statically, but that's kinda fragile.

[robrix]

@jspahrsummers Could you please give this branch a try again? (Assuming that you haven’t brew upgraded in the meantime 😁)

I’ve added symlinks to the .a files to External and removed the customized search paths, which means that it will use the (project-wide) External/ search path and try to resolve the .a files. Failing that it will try the other search paths, eventually ending up with system openssl dylibs.

So, brewed archives get top priority—meaning that recently-brewed libssh2 will work—and it should fallback otherwise. Only fly in the ointment is that you do have something at those paths—so now we just need to find out if it can link with it or not. (I’ve reason to expect “yes.”)

[jspahrsummers]

The above warning has disappeared too.

[robrix]

That’s good enough for me!

Ready for review.

🐚

[jspahrsummers]

Won't this have the same issue with dylib preference?

[robrix]

Both -lcrypto and -lssl are tested against $(SRCROOT)/External first, which has a libcrypto.a symlink in it. If that resolves, we’re done; otherwise, it falls back to system dylibs (which is fine).

[jspahrsummers]

1️⃣

[raheelahmad]

🙏 Thanks @robrix et al.

[robrix]

2️⃣

[jspahrsummers]

[robrix]

You’re welcome!