[geofft]

2016, and https://langui.sh/2015/07/24/osx-clang-include-lib-search-pa... (linked from the GitHub thread) seems to explain it better - if I understand right:

- Apple, in 2015, deprecated the version of OpenSSL they used to ship with the OS, which was the really old version 0.9.8. (The alternative is either Apple-specific crypto APIs or bringing your own OpenSSL.) The specific way they did that was to remove the development headers, but keep the runtime libraries around, so existing code would work but new code could not compile.

- For some reason, Apple's compiler searches /usr/local/include before /usr/include but their linker searches /usr/lib before /usr/local/lib.

- Homebrew's "link" operation puts libraries in /usr/local.

Therefore, if you were sufficiently unlucky, you could install a modern, up-to-date, secure OpenSSL from Homebrew in /usr/local via "brew link openssl," and have that used for the compile phase only, and end up actually using the deprecated, insecure OpenSSL in /usr, and you wouldn't notice anything had gone wrong.

[mosselman]

Thanks, your explanation makes it a lot more clear than the thread on GitHub.

Is there something we can do on our machines to quickly check if OpenSSL is setup ok so we don’t end up in the state you described where we use the old version?

[zetaposter]

Um. What the hell?

The linker/compiler discrepancy sounds incredibly weird. This Linux levels of "things don't work together as expected" but how can a uniform system developed by a sole company include nonsense like this?