configure.ac | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
New commits:
commit 2ba38d4f4147c3d07273e259559b2722bbe1d227
Author: Stephan Bergmann <sberg...@redhat.com>
AuthorDate: Thu Aug 4 11:41:40 2022 +0200
Commit: Stephan Bergmann <sberg...@redhat.com>
CommitDate: Thu Aug 4 19:08:25 2022 +0200
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 -lL
LVMInstCombine -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 <sberg...@redhat.com>
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(); ]])
