[kudu] branch master updated: [thirdparty] enable building curl with alternative OpenSSL

[al...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

alexey pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/kudu.git


The following commit(s) were added to refs/heads/master by this push:
     new 9bad249  [thirdparty] enable building curl with alternative OpenSSL
9bad249 is described below

commit 9bad2491cf91535eb1125a2b6bbe061ab4d41924
Author: Alexey Serbin <al...@apache.org>
AuthorDate: Wed Apr 14 12:48:23 2021 -0700

    [thirdparty] enable building curl with alternative OpenSSL
    
    If building curl in thirdparty when an alternative OpenSSL library
    is installed and pointed to by PATH and pkgconfig, the following
    compilation might happen:
    
      thirdparty/src/curl-7.68.0/lib/vtls/openssl.c: In function ‘Curl_ossl_seed’:
      thirdparty/src/curl-7.68.0/lib/vtls/openssl.c:500:15: error: implicit declaration of function ‘RAND_egd’; did you mean ‘RAND_add’? [-Werror=implicit-function-declaration]
           int ret = RAND_egd(data->set.str[STRING_SSL_EGDSOCKET]?
    		 ^~~~~~~~
    		 RAND_add
      cc1: some warnings being treated as errors
      make[1]: *** [Makefile:2067: libcurl_la-openssl.lo] Error 1
    
    The issue was in the configuration script -- it correctly found path
    for header files and the shared objects of the custom OpenSSL library,
    but since the system OpenSSL library was there as well, the order
    of paths in LDFLAGS made the "configure" script picking up the default
    library instead of the custom one.  The issue manifests itself only in
    environments where the difference between the default/OS OpenSSL library
    and the custom one contains some substantial difference in the API or
    build/configuration options.  For this particular case, those were
    'OpenSSL 1.0.1e-fips 11 Feb 2013' vs 'OpenSSL 1.1.1i  8 Dec 2020'
    for the default/OS and the custom OpenSSL library correspondingly.
    
    This patch addresses the issue by patching the configure.in script.
    
    Change-Id: Ia47c60b0dcef0212c777d628ab8c2f0be9c0a368
    Reviewed-on: http://gerrit.cloudera.org:8080/17318
    Tested-by: Kudu Jenkins
    Reviewed-by: Andrew Wong <aw...@cloudera.com>
---
 thirdparty/download-thirdparty.sh                    |  3 ++-
 thirdparty/patches/curl-custom-openssl-library.patch | 19 +++++++++++++++++++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/thirdparty/download-thirdparty.sh b/thirdparty/download-thirdparty.sh
index 1f6215f..944b00f 100755
--- a/thirdparty/download-thirdparty.sh
+++ b/thirdparty/download-thirdparty.sh
@@ -301,11 +301,12 @@ fetch_and_patch \
  $GCOVR_SOURCE \
  $GCOVR_PATCHLEVEL
 
-CURL_PATCHLEVEL=0
+CURL_PATCHLEVEL=1
 fetch_and_patch \
  curl-${CURL_VERSION}.tar.gz \
  $CURL_SOURCE \
  $CURL_PATCHLEVEL \
+ "patch -p1 < $TP_DIR/patches/curl-custom-openssl-library.patch" \
  "autoreconf -fvi"
 
 CRCUTIL_PATCHLEVEL=0
diff --git a/thirdparty/patches/curl-custom-openssl-library.patch b/thirdparty/patches/curl-custom-openssl-library.patch
new file mode 100644
index 0000000..af7117b
--- /dev/null
+++ b/thirdparty/patches/curl-custom-openssl-library.patch
@@ -0,0 +1,19 @@
+--- a/configure.ac	2021-04-14 12:03:20.819257209 -0700
++++ b/configure.ac	2021-04-14 12:27:51.050220736 -0700
+@@ -1715,9 +1715,13 @@
+     fi
+   fi
+ 
+-  dnl finally, set flags to use SSL
+-  CPPFLAGS="$CPPFLAGS $SSL_CPPFLAGS"
+-  LDFLAGS="$LDFLAGS $SSL_LDFLAGS"
++  dnl Finally, set flags to use SSL.
++  dnl If another version of OpenSSL library is present under the 'standard'
++  dnl system paths, it's necessary to pick up the header and binary files
++  dnl of the custom OpenSSL library, so put OpenSSL's custom paths first
++  dnl for both the preprocessor and the linker.
++  CPPFLAGS="$SSL_CPPFLAGS $CPPFLAGS"
++  LDFLAGS="$SSL_LDFLAGS $LDFLAGS"
+ 
+   AC_CHECK_LIB(crypto, HMAC_Update,[
+      HAVECRYPTO="yes"