Prefer -lclang-cpp over hand-curated -lclang* list

ad5cbcf6ba0afdc1d8d7405c2641cce8de4a360b "try to autodetect flags needed to
build Clang plugins" had added both, in that order, first a check for a
hand-curated list of individual -lclangTooling -lclangDriver -lclangFrontend ...
libs, and only then a fallback check for the combined -lclang-cpp.  It did not
give any rationale for that particular order.  But checking for the hand-curated
list first turned out to have the following drawback:  My build against recent
Clang 16 trunk succeeded the check for the hand-curated list but then failed
during the build because the hand-curated list missed to include a new
-lclangSupport dependency.  And my naive fix
5078591de9a0e65ca560a4f1913e90dfe95f66bf "CLANGTOOLLIBS needs to include
-lclangSupport now" caused further issues:

For one, I had naively assumed that libclangSupport.a would be available on our
compiler plugins Clang 12.0.1 baseline, not noticing that the corresponding
Jenkins build
<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/119581/> only
succeeded with

> checking for clang libraries to use... -lclang-cpp -L/home/tdf/lode/opt_private/clang-llvmorg-12.0.1/lib  -lLLVMWindowsManifest -lLLVMXRay -lLLVMLibDriver -lLLVMDlltoolDriver -lLLVMCoverage -lLLVMLineEditor -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Info -lLLVMOrcJIT -lLLVMMCJIT -lLLVMJITLink -lLLVMOrcTargetProcess -lLLVMOrcShared -lLLVMInterpreter -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMDebugInfoGSYM -lLLVMOption -lLLVMObjectYAML -lLLVMMCA -lLLVMMCDisassembler -lLLVMLTO -lLLVMPasses -lLLVMCFGuard -lLLVMCoroutines -lLLVMObjCARCOpts -lLLVMHelloNew -lLLVMipo -lLLVMVectorize -lLLVMLinker -lLLVMInstrumentation -lLLVMFrontendOpenMP -lLLVMFrontendOpenACC -lLLVMExtensions -lLLVMDWARFLinker -lLLVMGlobalISel -lLLVMMIRParser -lLLVMAsmPrinter -lLLVMDebugInfoDWARF -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMIRReader -lLLVMAsmParser -lLLVMInterfaceStub -lLLVMFileCheck -lLLVMFuzzMutate -lLLVMTarget -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMObject -lLLVMTextAPI -lLLVMMCParser -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMBitReader -lLLVMCore -lLLVMRemarks -lLLVMBitstreamReader -lLLVMBinaryFormat -lLLVMTableGen -lLLVMSupport -lLLVMDemangle -lrt -ldl -lpthread -lm -lz -ltinfo -lxml2

by silently falling back to -lclang-cpp after the check for the hand-curated
list had apparently failed due to the missing libclangSupport.a.  It turns out
libclangSupport.a only got added with
<https://github.com/llvm/llvm-project/commit/f26c41e8dd28d86030cd0f5a6e9c11036acea5d2>
"[RISCV] Moving RVV intrinsic type related util to clang/Support" towards
Clang 15.

And for another, as discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2022-August/089212.html>
"Re: Libreoffice error during autogen", there are apparently environments that
lack both libclangSupport.a and libclang-cpp.so, which then started to fail the
configure check completely.

Checking for the combined -lclang-cpp first avoids all of that (so this commit
effectively reverts 5078591de9a0e65ca560a4f1913e90dfe95f66bf "CLANGTOOLLIBS
needs to include -lclangSupport now" again).  The clang-cpp library should
generally be available since Clang 9 (see
<https://github.com/llvm/llvm-project/commit/a80a3a2b239591f62422686dae9071df89a3b339>
"Document clang-cpp in the release notes for clang"), but it can presumably be
configured not to be built, and there are apparently environments lacking it
(see above).  So keep checking for the (original, lacking the problematic
-lclangSupport) hand-curated list as a fallback, even though that list is known
to become outdated and dysfunctional.

Change-Id: I0edf23f5ca30b125e6438db0a42c849f1b4677d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137789
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

1 files changed, 7 insertions, 3 deletions

diff --git a/configure.ac b/configure.ac
index e17c3a345d4e..80150dcb725c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -8382,15 +8382,19 @@ if test "$COM_IS_CLANG" = "TRUE"; then
             LDFLAGS=""
             AC_MSG_CHECKING([for clang libraries to use])
             if test -z "$CLANGTOOLLIBS"; then
-                LIBS="-lclangTooling -lclangFrontend -lclangDriver -lclangParse -lclangSema -lclangEdit \
- -lclangAnalysis -lclangAST -lclangLex -lclangSerialization -lclangBasic -lclangSupport $COMPILER_PLUGINS_LINKFLAGS"
+                LIBS="-lclang-cpp $COMPILER_PLUGINS_LINKFLAGS"
                 AC_LINK_IFELSE([
                     AC_LANG_PROGRAM([[#include "clang/Basic/SourceLocation.h"]],
                         [[ clang::FullSourceLoc().dump(); ]])
                 ],[CLANGTOOLLIBS="$LIBS"],[])
             fi
+            dnl If the above check for the combined -lclang-cpp failed, fall back to a hand-curated
+            dnl list of individual -lclang* (but note that that list can become outdated over time,
+            dnl see e.g. the since-reverted 5078591de9a0e65ca560a4f1913e90dfe95f66bf "CLANGTOOLLIBS
+            dnl needs to include -lclangSupport now"):
             if test -z "$CLANGTOOLLIBS"; then
-                LIBS="-lclang-cpp $COMPILER_PLUGINS_LINKFLAGS"
+                LIBS="-lclangTooling -lclangFrontend -lclangDriver -lclangParse -lclangSema -lclangEdit \
+ -lclangAnalysis -lclangAST -lclangLex -lclangSerialization -lclangBasic $COMPILER_PLUGINS_LINKFLAGS"
                 AC_LINK_IFELSE([
                     AC_LANG_PROGRAM([[#include "clang/Basic/SourceLocation.h"]],
                         [[ clang::FullSourceLoc().dump(); ]])