aboutsummaryrefslogtreecommitdiff
path: root/gdb/configure.ac
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2021-11-20 12:22:03 +0100
committerTom de Vries <tdevries@suse.de>2021-11-20 12:22:03 +0100
commit0f8f2de1836941fe0c64ebac47e9a17a9063be86 (patch)
tree6db977014c6a843f3c41ed0323b73b0432f132f3 /gdb/configure.ac
parentd966a54ba936193aafeeb3a28bd2f2a54e25b564 (diff)
downloadgdb-0f8f2de1836941fe0c64ebac47e9a17a9063be86.zip
gdb-0f8f2de1836941fe0c64ebac47e9a17a9063be86.tar.gz
gdb-0f8f2de1836941fe0c64ebac47e9a17a9063be86.tar.bz2
[gdb/build] Check if libsource-highlight is usable
When building gdb with g++ 4.8.5, I ran into: ... ld: source-cache.o: in function `source_cache::ensure(symtab*)': source-cache.c:207: undefined reference to \ srchilite::SourceHighlight::SourceHighlight(std::string const&) ... [ I configured gdb without explicit settings related to source-highlight, so we're excercising the enable_source_highlight=auto scenario. ] The problem is that: - the source-highlight library is build with system compiler g++ 7.5.0 which uses the new libstdc++ library abi (see https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html ) - gdb is build using g++ 4.8.5 which uses the old abi. [ There's a compatibility macro _GLIBCXX_USE_CXX11_ABI, but that doesn't work for this case. Instead, it enables the opposite case where the source-highlight library is build with g++ 4.8.5 and gdb is build with g++ 7.5.0. ] Fix this by checking whether the source-highlight library is usable during configuration. In the enable_source_highlight=auto scenario, this allows the build to skip the unusable library and finish successfully. In the enable_source_highlight=yes scenario, this allows the build to error out earlier. Tested on x86_64-linux.
Diffstat (limited to 'gdb/configure.ac')
-rw-r--r--gdb/configure.ac47
1 files changed, 42 insertions, 5 deletions
diff --git a/gdb/configure.ac b/gdb/configure.ac
index d4cfb6a..56e8a2d 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -1248,11 +1248,48 @@ either use --disable-source-highlight or dnl
;;
esac
- SRCHIGH_CFLAGS=`${pkg_config_prog_path} --cflags source-highlight`
- SRCHIGH_LIBS=`${pkg_config_prog_path} --libs source-highlight`
- AC_DEFINE([HAVE_SOURCE_HIGHLIGHT], 1,
- [Define to 1 if the source-highlight library is available])
- AC_MSG_RESULT([yes])
+ srchigh_pkg_cflags=`${pkg_config_prog_path} --cflags source-highlight`
+ srchigh_pkg_libs=`${pkg_config_prog_path} --libs source-highlight`
+
+ # Now that we have found a source-highlight library, check if we can use
+ # it. In particular, we're trying to detect the situation that the
+ # library is using the new libstdc++ library abi ( see
+ # https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html )
+ # while the compiler being used to compile gdb is using the old abi.
+ # Such a situation will result in an undefined reference to
+ # srchilite::SourceHighlight::SourceHighlight(std::string const&).
+ # This situation can occur for instance when using a source highlight
+ # library compiled with g++ 7.5.0 while building gdb with g++ 4.8.5.
+ AC_LANG_PUSH(C++)
+ save_CFLAGS=$CFLAGS
+ save_LDFLAGS=$LDFLAGS
+ CFLAGS="$CFLAGS $srchigh_pkg_cflags"
+ LDFLAGS="$LDFLAGS $srchigh_pkg_libs"
+ AC_LINK_IFELSE(
+ [AC_LANG_PROGRAM(
+ [#include <srchilite/sourcehighlight.h>],
+ [std::string outlang = "esc.outlang";
+ new srchilite::SourceHighlight (outlang);]
+ )],
+ [have_usable_source_highlight=yes],
+ [have_usable_source_highlight=no]
+ )
+ CFLAGS="$SAVE_CFLAGS"
+ LDFLAGS="$SAVE_LDFLAGS"
+ AC_LANG_POP(C++)
+
+ if test "${have_usable_source_highlight}" = "yes"; then
+ AC_DEFINE([HAVE_SOURCE_HIGHLIGHT], 1,
+ [Define to 1 if the source-highlight library is available])
+ AC_MSG_RESULT([yes])
+ SRCHIGH_CFLAGS="$srchigh_pkg_cflags"
+ SRCHIGH_LIBS="$srchigh_pkg_libs"
+ else
+ AC_MSG_RESULT([no])
+ if test "${enable_source_highlight}" = "yes"; then
+ AC_MSG_ERROR([source-highlight in your system could not be used])
+ fi
+ fi
else
AC_MSG_RESULT([no])
if test "${enable_source_highlight}" = "yes"; then