![Sad Libs Mac OS Sad Libs Mac OS](https://images.macrumors.com/t/SX9BUoG148npK39c1StmWbIMo5c=/1600x1200/smart/article-new/2019/06/macos-catalina-apple-music.jpg)
3 thoughts on “ SharpZipLib and Mac OS X ” Pingback: Reliably Broken » SharpZipLib and Mac redux Andrew 23 September, 2014 at 3:01 am. Thanks David, had Mac users coming to me about this and it was driving me nuts. Darwin89= 32-bit for Mac OS X 10.4 or higher, 64-bit for Mac OS X 10.5 or higher darwin9 = for Mac OS X 10.5 (Leopard) or higher darwin10 = for Mac OS X 10.6 (Snow Leopard) or higher darwin13 = for Mac OS X 10.9 (Mavericks) or higher darwin15 = for Mac OS X 10.11 (El Capitan) or higher It is safe to use darwin8 binaries on Mac OX S 10.5 (Leopard).
July 24th, 2015 A recent (and even more recently reverted) change to Homebrew highlighted an interesting (read: maddening) quirk of clang on OS X. Here’s the background.
When you compile something using clang on OS X there are (roughly speaking) two stages to the compile. In the first, your source code is loaded and the compiler searches its include paths to find your includes. Here’s what clang’s defaults look like for the Xcode 6.4 command line tools:
Sad Libs Mac Os X
![Sad Libs Mac OS Sad Libs Mac OS](https://images.squarespace-cdn.com/content/v1/54d696e5e4b05ca7b54cff5c/1551197585497-D4FRH6F6HEMUQZKDE7PX/ke17ZwdGBToddI8pDm48kFWM1EEMzDsIC5TYUy2DskNZw-zPPgdn4jUwVcJE1ZvWQUxwkmyExglNqGp0IvTJZUJFbgE-7XRK3dMEBRBhUpy3oCHSsCoopulhrd9XDjQOgcTAgSZc1PZaApGpMl8fbstWtc4KmnlWs_u_Q5yXoJw/macOS-Mojave-Energey-Saver-Preference-Pane.jpg)
As you can see, the include search starts with
/usr/local/include
and /usr/include
is the fourth item. So, in the case of a vanilla OS X install a binary attempting to compile using OpenSSL (let’s say #include <openssl/x509.h>
) would find the OpenSSL headers in /usr/include
after searching the previous 3 locations fruitlessly.Once it’s found (and the C preprocessor has run and all the objects have been compiled) we now need to link it. When compiling something against OpenSSL you’ll link against
-lssl
, -lcrypto
, or both. These command line flags simply tell the linker to look for something named “libssl.dylib” or “libcrypto.dylib” in the library search paths. But what are those paths?This time we see two primary library search paths,
/usr/lib
and /usr/local/lib
…which are reversed in priority from our include search path.The result of this is that if you have something (like OpenSSL) that is present in both
/usr/local/{include,lib}
and /usr/{include,lib}
you’ll end up with the compiler using the headers from /usr/local/include
and then linking against the library in /usr/lib
. This can result in a variety of problems, the severity of which depend on how different the two versions of the library are and what features the binary you’re compiling is using.Mac Os Catalina
So why does this matter? Well, in El Capitan (10.11) Apple has chosen to remove the OpenSSL development headers, but not remove the dylibs. They deprecated use of system OpenSSL in Lion (10.7) so this makes sense on the surface, but the weird include/linker ordering means that if homebrew (or anything else living in your include/search paths) duplicates a system library bad things may occur. Bat hat mac os. There are four possible paths (all of which are under the control of Apple and not us plebes):
Sad Libs Mac Os Catalina
- Change the linker order preference. Probably a good idea long term but likely to cause all sorts of unintended breakage as we find things that are implicitly depending on this crazy ordering.
- Re-add the OpenSSL headers for 0.9.8. Not a great option since 0.9.8 is scheduled for EOL at the end of this year and Apple has marked it deprecated in OS X since Lion (originally released July 20, 2011), but probably the safest and lowest friction option.
- Remove OpenSSL entirely. This would break any OS X app that links against it and would require Apple to ship updates to Ruby, Python, Apache, etc that statically link OpenSSL (or go down the route of a “private” dylib like they’ve done with OpenSSH in El Capitan)
- Do nothing and let this be a significant source of pain for developers during El Capitan’s lifecycle. This is the most likely scenario.
Sad Libs Mac Os Catalina
I favor either removing the OpenSSL dylibs entirely for El Capitan or re-adding the OpenSSL headers and then removing everything in the next major release, but I don’t envy whoever has to make this choice. Everything has downsides.