On Sun, 9 Jun 2024, Alexander Dyagilev via curl-library wrote:
Yes, this OpenSSL 3 version was installed into /usr/local by Homebrew.
The problem is that you have a setup that makes curl think it builds with
OpenSSL 3 (because if the headers) but you link with OpenSSL 1 libs.
So, you think it's Homebew's fault?
Yes. We know for a fact that Homebrew has messed up this up for a while. It
started at some point around July 2023. Because of that, in our CI jobs on
macOS we do this to be sure we can build with a custom OpenSSL path:
https://github.com/curl/curl/commit/5c07439ba3345cef3eb158a
ie: we uninstall their openssl explictly first, so that their installation
isn't ruining setting up a custom version.
In my opinion, if I set an explicit path to OpenSSL, it must be used instead
of any other locations. Thus, -isystem must never be used for custom paths
to libs. Am I wrong? Why?
-isystem works perfectly fine for custom paths. I was not kidding when I said
that we have used -isystem in the curl build for twenty years. We did
introduced use of it in the year of 2004 and quite a few people have built
curl successfully with custom OpenSSL versions over the years.
The problem is that Homebrew puts their own OpenSSL first in the include path
*before* the first -isystem path and that breaks builds.
This is not a curl bug. This is Homebrew breaking how this has worked on a
numerous systems through decades. They basically assume nobody wants to build
with a custom OpenSSL. You should probably ask them why they did this, I have
no idea.
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
