Skip to content
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

Merged
merged 2 commits into from
Jun 30, 2023

Conversation

kou
Copy link
Member

@kou kou commented Jun 28, 2023

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.

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.
@github-actions
Copy link

⚠️ GitHub issue #36329 has been automatically assigned in GitHub to PR creator.

@kou
Copy link
Member Author

kou commented Jun 28, 2023

+1

The "C++ / AMD64 macOS 12 C++" is still failing but it's caused by #36331/#36248 .

OUTPUT_STRIP_TRAILING_WHITESPACE)
if(OPENSSL_BREW_PREFIX)
set(OPENSSL_ROOT_DIR ${OPENSSL_BREW_PREFIX})
if(OPENSSL11_BREW_PREFIX)
Copy link
Member

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?

Copy link
Member Author

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"
Copy link
Member

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...

Copy link
Member Author

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.

@raulcd
Copy link
Member

raulcd commented Jun 28, 2023

@github-actions crossbow submit java-jars

@raulcd
Copy link
Member

raulcd commented Jun 28, 2023

Triggering java-jars because they seem to be failing on the nightlies due to this reason:

 Undefined symbols for architecture arm64:
  "_EVP_MD_get_size", referenced from:
      gandiva::gdv_hash_using_openssl(long long, void const*, unsigned long, evp_md_st const*, unsigned int, int*) in libgandiva.a(unity_3_cxx.cxx.o)
ld: symbol(s) not found for architecture arm64

@github-actions
Copy link

Revision: fc0a16e

Submitted crossbow builds: ursacomputing/crossbow @ actions-b784334a54

Task Status
java-jars Github Actions

@raulcd
Copy link
Member

raulcd commented Jun 28, 2023

There seems to be a lot of failures around gandiva on the MacOs java-jars job. I am not sure if they are related:

 The following tests FAILED:
	 20 - arrow-compute-scalar-type-test (Failed)
	 38 - arrow-substrait-substrait-test (Failed)
	 44 - arrow-acero-asof-join-node-test (Failed)
	 78 - gandiva-internals-test (Failed)
	 80 - gandiva-filter-test (Failed)
	 81 - gandiva-projector-test (Failed)
	 82 - gandiva-projector-build-validation-test (Failed)
	 83 - gandiva-if-expr-test (Failed)
	 84 - gandiva-literal-test (Failed)
	 85 - gandiva-boolean-expr-test (Failed)
	 86 - gandiva-binary-test (Failed)
	 87 - gandiva-date-time-test (Failed)
	 88 - gandiva-to-string-test (Failed)
	 89 - gandiva-utf8-test (Failed)
	 90 - gandiva-hash-test (Failed)
	 91 - gandiva-in-expr-test (Failed)
	 92 - gandiva-null-validity-test (Failed)
	 93 - gandiva-decimal-test (Failed)
	 94 - gandiva-decimal-single-test (Failed)
	 95 - gandiva-filter-project-test (Failed)
	 96 - gandiva-projector-test-static (Failed)

@github-actions github-actions bot added awaiting changes Awaiting changes and removed awaiting committer review Awaiting committer review labels Jun 29, 2023
@github-actions github-actions bot added awaiting change review Awaiting change review and removed awaiting changes Awaiting changes labels Jun 29, 2023
@kou
Copy link
Member Author

kou commented Jun 29, 2023

gandiva-* tests were crashed without backtrace... So we can't debug this. We may be able debug this by ssh to the host.

Anyway, how about tracking the failures as a separated issue? Because Gandiva tests in "AMD64 macOS 12 C++" aren't failed.

@raulcd
Copy link
Member

raulcd commented Jun 29, 2023

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.

@kou
Copy link
Member Author

kou commented Jun 30, 2023

Created: #36404

I'll merge this.

@kou kou merged commit 9d92ed4 into apache:main Jun 30, 2023
28 of 31 checks passed
@kou kou deleted the cpp-macos-gandiva-openssl branch June 30, 2023 00:41
@kou kou removed the awaiting change review Awaiting change review label Jun 30, 2023
@conbench-apache-arrow
Copy link

Conbench analyzed the 6 benchmark runs on commit 9d92ed4d.

There were 5 benchmark results indicating a performance regression:

The full Conbench report has more details.

lriggs pushed a commit to lriggs/arrow that referenced this pull request Jul 19, 2023
### 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>
lriggs pushed a commit to dremio/arrow that referenced this pull request Jul 21, 2023
### 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>
xxlaykxx added a commit to dremio/arrow that referenced this pull request Jul 30, 2023
### 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[C++][CI] OpenSSL link error in Gandiva on macOS
3 participants