-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-36329: [C++][CI] Use OpenSSL 3 on macOS #36336
Conversation
GitHub Actions self-hosted runner for macOS has /usr/local/include/openssl/ provided by OpenSSL 3 (`openssl@3`). Our include paths have `... -isystem /usr/local/include -isystem /usr/local/opt/openssl@1.1/include ...`. It means that `/usr/local/include/openssl/...` is used for `#include <openssl/...>`. If we mix OpenSSL 3 headers and OpenSSL 1.1 libraries, we may get some problems such as a link error. This uses OpenSSL 3 instead of OpenSSL 1.1 because GitHub Actions self-hosted runner for macOS provides OpenSSL 3 by /usr/local/include/openssl/. Note that `$(brew --prefix openssl@3)/include` isn't linked as /usr/local/include/openssl` by default. So I think that Homebrew GitHub Actions self-hosted runner for macOS does it explicitly. Other solution: Unlinking `/usr/local/include/openssl` by `brew unlink openssl@3`. But there is no reason to use OpenSSL 1.1 for us. So this PR doesn't use this solution.
|
OUTPUT_STRIP_TRAILING_WHITESPACE) | ||
if(OPENSSL_BREW_PREFIX) | ||
set(OPENSSL_ROOT_DIR ${OPENSSL_BREW_PREFIX}) | ||
if(OPENSSL11_BREW_PREFIX) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be OPENSSL3_BREW_PREFIX
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes. Good catch!
Ah, wait. I should have used OPENSSL30_...
for it.
@@ -22,17 +22,24 @@ endif() | |||
if(APPLE AND NOT OPENSSL_ROOT_DIR) | |||
find_program(BREW brew) | |||
if(BREW) | |||
execute_process(COMMAND ${BREW} --prefix "openssl@1.1" | |||
OUTPUT_VARIABLE OPENSSL11_BREW_PREFIX | |||
execute_process(COMMAND ${BREW} --prefix "openssl" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious: why first try "openssl", then "openssl@3.0", then "openssl@1.1"?
Wouldn't "openssl" cover all other cases? I don't know how brew works...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
openssl
is the default OpenSSL formula. In general, it refers the latest OpenSSL formula (openssl@3.1
now).
If openssl@3.1
isn't installed, brew --prefix openssl
is failed.
Then, this process falls back to openssl@3.0
, then openssl@1.1
. Because we want to use newer OpenSSL as much as possible.
@github-actions crossbow submit java-jars |
Triggering java-jars because they seem to be failing on the nightlies due to this reason:
|
Revision: fc0a16e Submitted crossbow builds: ursacomputing/crossbow @ actions-b784334a54
|
There seems to be a lot of failures around
|
Anyway, how about tracking the failures as a separated issue? Because Gandiva tests in "AMD64 macOS 12 C++" aren't failed. |
Sounds good to me. |
Created: #36404 I'll merge this. |
Conbench analyzed the 6 benchmark runs on commit There were 5 benchmark results indicating a performance regression:
The full Conbench report has more details. |
### Rationale for this change GitHub Actions self-hosted runner for macOS has /usr/local/include/openssl/ provided by OpenSSL 3 (`openssl@ 3`). Our include paths have `... -isystem /usr/local/include -isystem /usr/local/opt/openssl@ 1.1/include ...`. It means that `/usr/local/include/openssl/...` is used for `#include <openssl/...>`. If we mix OpenSSL 3 headers and OpenSSL 1.1 libraries, we may get some problems such as a link error. ### What changes are included in this PR? This uses OpenSSL 3 instead of OpenSSL 1.1 because GitHub Actions self-hosted runner for macOS provides OpenSSL 3 by /usr/local/include/openssl/. Note that `$(brew --prefix openssl@ 3)/include` isn't linked as /usr/local/include/openssl` by default. So I think that Homebrew GitHub Actions self-hosted runner for macOS does it explicitly. Other solution: Unlinking `/usr/local/include/openssl` by `brew unlink openssl@ 3`. But there is no reason to use OpenSSL 1.1 for us. So this PR doesn't use this solution. ### Are these changes tested? Yes. ### Are there any user-facing changes? Yes. * Closes: apache#36329 Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>
### Rationale for this change GitHub Actions self-hosted runner for macOS has /usr/local/include/openssl/ provided by OpenSSL 3 (`openssl@ 3`). Our include paths have `... -isystem /usr/local/include -isystem /usr/local/opt/openssl@ 1.1/include ...`. It means that `/usr/local/include/openssl/...` is used for `#include <openssl/...>`. If we mix OpenSSL 3 headers and OpenSSL 1.1 libraries, we may get some problems such as a link error. ### What changes are included in this PR? This uses OpenSSL 3 instead of OpenSSL 1.1 because GitHub Actions self-hosted runner for macOS provides OpenSSL 3 by /usr/local/include/openssl/. Note that `$(brew --prefix openssl@ 3)/include` isn't linked as /usr/local/include/openssl` by default. So I think that Homebrew GitHub Actions self-hosted runner for macOS does it explicitly. Other solution: Unlinking `/usr/local/include/openssl` by `brew unlink openssl@ 3`. But there is no reason to use OpenSSL 1.1 for us. So this PR doesn't use this solution. ### Are these changes tested? Yes. ### Are there any user-facing changes? Yes. * Closes: apache#36329 Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com>
### Rationale for this change GitHub Actions self-hosted runner for macOS has /usr/local/include/openssl/ provided by OpenSSL 3 (`openssl@ 3`). Our include paths have `... -isystem /usr/local/include -isystem /usr/local/opt/openssl@ 1.1/include ...`. It means that `/usr/local/include/openssl/...` is used for `#include <openssl/...>`. If we mix OpenSSL 3 headers and OpenSSL 1.1 libraries, we may get some problems such as a link error. ### What changes are included in this PR? This uses OpenSSL 3 instead of OpenSSL 1.1 because GitHub Actions self-hosted runner for macOS provides OpenSSL 3 by /usr/local/include/openssl/. Note that `$(brew --prefix openssl@ 3)/include` isn't linked as /usr/local/include/openssl` by default. So I think that Homebrew GitHub Actions self-hosted runner for macOS does it explicitly. Other solution: Unlinking `/usr/local/include/openssl` by `brew unlink openssl@ 3`. But there is no reason to use OpenSSL 1.1 for us. So this PR doesn't use this solution. ### Are these changes tested? Yes. ### Are there any user-facing changes? Yes. * Closes: apache#36329 Authored-by: Sutou Kouhei <kou@clear-code.com> Signed-off-by: Sutou Kouhei <kou@clear-code.com> Co-authored-by: Sutou Kouhei <kou@clear-code.com>
Rationale for this change
GitHub Actions self-hosted runner for macOS has
/usr/local/include/openssl/ provided by OpenSSL 3 (
openssl@3
). Our include paths have... -isystem /usr/local/include -isystem /usr/local/opt/openssl@1.1/include ...
. It means that/usr/local/include/openssl/...
is used for#include <openssl/...>
.If we mix OpenSSL 3 headers and OpenSSL 1.1 libraries, we may get some problems such as a link error.
What changes are included in this PR?
This uses OpenSSL 3 instead of OpenSSL 1.1 because GitHub Actions self-hosted runner for macOS provides OpenSSL 3 by /usr/local/include/openssl/. Note that
$(brew --prefix openssl@3)/include
isn't linked as /usr/local/include/openssl` by default. So I think that Homebrew GitHub Actions self-hosted runner for macOS does it explicitly.Other solution: Unlinking
/usr/local/include/openssl
bybrew unlink openssl@3
. But there is no reason to use OpenSSL 1.1 for us. So this PR doesn't use this solution.Are these changes tested?
Yes.
Are there any user-facing changes?
Yes.