Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Fwd: OpenSSL 1.x support?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 10 Jun 2024 08:59:11 +0200 (CEST)
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.
Date: Mon, 10 Jun 2024 08:59:11 +0200 (CEST)
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.htmlReceived on 2024-06-10