diff options
author | Tom de Vries <tdevries@suse.de> | 2021-11-20 12:22:03 +0100 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2021-11-20 12:22:03 +0100 |
commit | 0f8f2de1836941fe0c64ebac47e9a17a9063be86 (patch) | |
tree | 6db977014c6a843f3c41ed0323b73b0432f132f3 /gdb/configure.ac | |
parent | d966a54ba936193aafeeb3a28bd2f2a54e25b564 (diff) | |
download | gdb-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.ac | 47 |
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 |