Bug 1278135 - Link against less of Clang and LLVM statically when building the...

Bug 1278135 - Link against less of Clang and LLVM statically when building the clang plugin, r=glandium

build/autoconf/clang-plugin.m4

@@ -37,24 +37,26 @@ if test -n "$ENABLE_CLANG_PLUGIN"; then
     if test -z "$LLVMCONFIG"; then
         AC_MSG_ERROR([Cannot find an llvm-config binary for building a clang plugin])
     fi
-    LLVM_CXXFLAGS=`$LLVMCONFIG --cxxflags`
-    dnl The clang package we use on OSX is old, and its llvm-config doesn't
-    dnl recognize --system-libs, so ask for that separately.  llvm-config's
-    dnl failure here is benign, so we can ignore it if it happens.
-    dnl Use tr instead of xargs in order to avoid problems with path separators on Windows.
-    LLVM_LDFLAGS=`$LLVMCONFIG --system-libs | tr '\n' ' '`
-    LLVM_LDFLAGS="$LLVM_LDFLAGS `$LLVMCONFIG --ldflags --libs core mc analysis asmparser mcparser bitreader option profiledata | tr '\n' ' '`"
+    dnl For some reason the llvm-config downloaded from clang.llvm.org for clang3_8
+    dnl produces a -isysroot flag for a sysroot which might not ship when passed
+    dnl --cxxflags. We use sed to remove this argument so that builds work on OSX
+    LLVM_CXXFLAGS=`$LLVMCONFIG --cxxflags | sed -e 's/-isysroot [[^ ]]*//'`
+
+    dnl We are loaded into clang, so we don't need to link to very many things,
+    dnl we just need to link to clangASTMatchers because it is not used by clang
+    LLVM_LDFLAGS=`$LLVMCONFIG --ldflags | tr '\n' ' '`
 
     if test "${HOST_OS_ARCH}" = "Darwin"; then
-        CLANG_LDFLAGS="-lclangFrontend -lclangDriver -lclangSerialization"
-        CLANG_LDFLAGS="$CLANG_LDFLAGS -lclangParse -lclangSema -lclangAnalysis"
-        CLANG_LDFLAGS="$CLANG_LDFLAGS -lclangEdit -lclangAST -lclangLex"
-        CLANG_LDFLAGS="$CLANG_LDFLAGS -lclangBasic -lclangASTMatchers"
+        dnl We need to make sure that we use the symbols coming from the clang
+        dnl binary. In order to do this, we need to pass -flat_namespace and
+        dnl -undefined suppress to the linker. This makes sure that we link the
+        dnl symbols into the flat namespace provided by clang, and thus get
+        dnl access to all of the symbols which are undefined in our dylib as we
+        dnl are building it right now, and also that we don't fail the build
+        dnl due to undefined symbols (which will be provided by clang).
+        CLANG_LDFLAGS="-Wl,-flat_namespace -Wl,-undefined,suppress -lclangASTMatchers"
     elif test "${HOST_OS_ARCH}" = "WINNT"; then
-        CLANG_LDFLAGS="clangFrontend.lib clangDriver.lib clangSerialization.lib"
-        CLANG_LDFLAGS="$CLANG_LDFLAGS clangParse.lib clangSema.lib clangAnalysis.lib"
-        CLANG_LDFLAGS="$CLANG_LDFLAGS clangEdit.lib clangAST.lib clangLex.lib"
-        CLANG_LDFLAGS="$CLANG_LDFLAGS clangBasic.lib clangASTMatchers.lib"
+        CLANG_LDFLAGS="clangASTMatchers.lib"
     else
         CLANG_LDFLAGS="-lclangASTMatchers"
     fi
@@ -102,6 +104,8 @@ if test -n "$ENABLE_CLANG_PLUGIN"; then
             AC_LANG_CPLUSPLUS
             _SAVE_CXXFLAGS="$CXXFLAGS"
             _SAVE_CXX="$CXX"
+            _SAVE_MACOSX_DEPLOYMENT_TARGET="$MACOSX_DEPLOYMENT_TARGET"
+            unset MACOSX_DEPLOYMENT_TARGET
             CXXFLAGS="${LLVM_CXXFLAGS}"
             CXX="${HOST_CXX}"
             AC_TRY_COMPILE([#include "clang/ASTMatchers/ASTMatchers.h"],
@@ -110,6 +114,7 @@ if test -n "$ENABLE_CLANG_PLUGIN"; then
                            ac_cv_have_new_ASTMatcher_names="no")
             CXX="$_SAVE_CXX"
             CXXFLAGS="$_SAVE_CXXFLAGS"
+            export MACOSX_DEPLOYMENT_TARGET="$_SAVE_MACOSX_DEPLOYMENT_TARGET"
             AC_LANG_RESTORE
         ])
     if test "$ac_cv_have_new_ASTMatcher_names" = "yes"; then