[
https://issues.apache.org/jira/browse/ARROW-10138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17204806#comment-17204806
]
Neal Richardson commented on ARROW-10138:
-----------------------------------------
All reasonable concerns [~apitrou], but as you yourself [point
out|https://github.com/apache/arrow/pull/8243#issuecomment-697352808], we
already do build and bundle openssl in the Python wheels. I'm not proposing
that we add bundled openssl to any binary packages we currently ship--I'm
proposing that we add a {{build_openssl}} macro to our cmake so that if (1) you
are building the C++ library with some configuration that requires openssl, (2)
you don't have openssl on your system, and (3) you have
ARROW_DEPENDENCY_SOURCE=AUTO, the build falls back to the bundled openssl build
and doesn't fail.
As long as that is the purpose, IIUC I don't think your concern #2 is an issue:
we won't have symbol clashes because we're only building openssl if openssl
isn't found on the system. And if we aren't adding bundled openssl to any of
our packages, we don't have upgrades to ship (concern #1). Moreover, if the
externalproject always installs latest openssl, not a pinned version, then even
a local Arrow build from source with bundled openssl is upgraded by just
rebuilding Arrow.
> [C++] Bundled external project for openssl
> ------------------------------------------
>
> Key: ARROW-10138
> URL: https://issues.apache.org/jira/browse/ARROW-10138
> Project: Apache Arrow
> Issue Type: New Feature
> Components: C++, Packaging
> Reporter: Neal Richardson
> Priority: Major
> Fix For: 2.0.0
>
>
> aws-sdk-cpp requires it and it seems easy enough to build. Arguably you
> *should* manage openssl as a system package but that's not always feasible
> for all of our packages, and the manylinux wheel scripts already build and
> bundle openssl.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
