[kudu] branch master updated: [thirdparty] fix building 3rd-party on SLES 12.5 with GCC8

[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 de0a1df  [thirdparty] fix building 3rd-party on SLES 12.5 with GCC8
de0a1df is described below

commit de0a1df8efb141641d8e65846b45708261a7de6f
Author: Alexey Serbin <al...@apache.org>
AuthorDate: Mon Dec 14 21:34:54 2020 -0800

    [thirdparty] fix building 3rd-party on SLES 12.5 with GCC8
    
    This patch updates build-definitions.sh to allow building on SLES 12.5
    (SUSE Linux Enterprise Server 12 SP5) with GCC 8.
    
    The stock C/C++ compiler on SLES 12 doesn't support C++17 features now
    required to build Kudu, so one option is to use gcc/g++-8.
    
    Another option might be building with Development Tools Module [1],
    but I guess it's nice to be able to build Kudu with just other/newer
    C++ compiler at first.
    
    I used the following script to build all thirdparty components from
    Kudu workspace root:
    
    -------------------
    
    CC=/usr/bin/gcc-8
    CXX=/usr/bin/g++-8
    
    env CC=$CC CXX=$CXX \
      ./build-support/enable_devtoolset.sh thirdparty/build-if-necessary.sh all
    -------------------
    
    [1] https://www.suse.com/c/suse-linux-essentials-where-are-the-compilers-understanding-the-development-tools-module/
    
    Change-Id: If5ad79e1a3582a64015bb34a8b615b1cbeab49f7
    Reviewed-on: http://gerrit.cloudera.org:8080/16878
    Tested-by: Alexey Serbin <as...@cloudera.com>
    Reviewed-by: Grant Henke <gr...@apache.org>
---
 thirdparty/build-definitions.sh | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/thirdparty/build-definitions.sh b/thirdparty/build-definitions.sh
index 3baf422..21713fb 100644
--- a/thirdparty/build-definitions.sh
+++ b/thirdparty/build-definitions.sh
@@ -840,16 +840,18 @@ build_boost() {
 
   # If CC and CXX are set, set the compiler in user-config.jam.
   if [ -n "$CC" -a -n "$CXX" ]; then
-    # Determine the name of the compiler referenced in $CC. This assumes
-    # the compiler prints its name in the first line of the output. The pattern
+    # Determine the name of the compiler referenced in $CC. The pattern
     # matching works for various flavors of GCC and LLVM clang. As the last
-    # resort, output the first word of the first line. The '$CC --version'
-    # approach appears to work even if the compiler is called through ccache.
-    local COMPILER=$($CC --version | \
-      awk '/(Apple )?(clang|LLVM) version [[:digit:]]+\.[[:digit:]]+/ {
-             print "clang"; exit }
-           /\(GCC\) [[:digit:]]+\.[[:digit:]]+/{ print "gcc"; exit }
-           { print $1; exit }')
+    # resort, output the first word of the line containing version information.
+    # The '$CC -v 2>&1' approach appears to work even if the compiler is
+    # called through ccache, and the version line keeps the same format on
+    # different OS and flavors, whereas '$CC --version' is plagued by many
+    # variations depending on the OS flavor and versioning/packaging nuances.
+    local COMPILER=$($CC -v 2>&1 | grep -E ' version [[:digit:]]' | awk '
+        /^(Apple )?(clang|LLVM) version [[:digit:]]+\.[[:digit:]]+/ { print "clang"; exit }
+        /^gcc version [[:digit:]]+\.[[:digit:]]+/ { print "gcc"; exit }
+        { print $1; exit }
+    ')
 
     # If the compiler binary used was 'cc' and not 'gcc', it will also report
     # itself as 'cc'. Coerce it to gcc.
@@ -866,7 +868,12 @@ build_boost() {
   fi
 
   # Build the date_time boost lib.
-  ./bootstrap.sh --prefix=$PREFIX threading=multi --with-libraries=date_time
+  if [ -z "$TOOLSET" ]; then
+    ./bootstrap.sh --prefix=$PREFIX threading=multi --with-libraries=date_time
+  else
+    ./bootstrap.sh --prefix=$PREFIX threading=multi --with-libraries=date_time \
+        --with-toolset=$COMPILER
+  fi
   ./b2 clean $TOOLSET --build-dir="$BOOST_BDIR"
   ./b2 install variant=release link=static,shared --build-dir="$BOOST_BDIR" $TOOLSET -q -d0 \
     --debug-configuration \