[gdb/build] Hardcode --with-included-regex

Currently gdb has a configure option:
...
$ ./src/gdb/configure --help
  ...
  --without-included-regex
                          don't use included regex; this is the default on
                          systems with version 2 of the GNU C library (use
                          with caution on other system)
...

The configure option controls config.h macro USE_INCLUDED_REGEX, which is
used in gdb/gdb_regex.h to choose between:
- using regex from libiberty (which is included in the binutils-gdb.git repo,
  hence the 'included' in USE_INCLUDED_REGEX), or
- using regex.h.

In the former case, the symbol regcomp is remapped to a symbol xregcomp, which
is then provided by libiberty.

In the latter case, the symbol regcomp is resolved at runtime, usually binding
to libc.  However, there is no mechanism in place to enforce this.

PR27681 is an example of where that causes problems.  On openSUSE Tumbleweed,
the ncurses package got the --with-pcre2 configure switch enabled, and solved
the resulting dependencies using:
...
 $ cat /usr/lib64/libncursesw.so
 /* GNU ld script */
-INPUT(/lib64/libncursesw.so.6 AS_NEEDED(-ltinfo -ldl))
+INPUT(/lib64/libncursesw.so.6 AS_NEEDED(-ltinfo -ldl -lpcre2-posix -lpcre2-8))
...

This lead to regcomp being bound to libpcre2-posix instead of libc.

This causes problems in several ways:
- by compiling using regex.h, we've already chosen a specific regex_t
  implementation, and the one from pcre2-posix is not the same.
- in gdb_regex.c we use GNU regex function re_search, which pcre2-posix
  doesn't provide, so while regcomp binds to pcre2-posix, re_search binds to
  libc.

A note on the latter: it's actually a bug to compile a regex using regcomp and
then pass it to re_search.  The GNU regex interface requires one to use
re_compile_pattern or re_compile_fastmap.  But as long we're using one of the
GNU regex incarnations in gnulib, glibc or libiberty, we get away with this.

The PR could be fixed by adding -lc in a specific position in the link line,
to force regcomp to be bound to glibc.  But this solution was considered
in the discussion in the PR as being brittle, and possibly causing problems
elsewhere.

Another solution offered was to restrict regex usage to posix, and no longer
use the GNU regex API.  This however could mean having to reproduce some of
that functionality locally, which would mean maintaining the same
functionality in more than one place.

The solution chosen here, is to hardcode --with-included-regex, that is, using
libiberty.

The option of using glibc for regex was introduced because glibc became the
authorative source for GNU regex, so it offered the possibility to link
against a more up-to-date regex version.

In that aspect, this patch is a step back.  But we have the option of using a
more up-to-date regex version as a follow-up step: by using the regex from
gnulib.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-04-21  Tom de Vries  <tdevries@suse.de>

	PR build/27681
	* configure.ac: Remove --without-included-regex/--with-included-regex.
	* config.in: Regenerate.
	* configure: Regenerate.
	* gdb_regex.h: Assume USE_INCLUDED_REGEX is defined.

1 files changed, 0 insertions, 6 deletions

diff --git a/gdb/gdb_regex.h b/gdb/gdb_regex.h
index afe9909..0cac96e 100644
--- a/gdb/gdb_regex.h
+++ b/gdb/gdb_regex.h
@@ -19,13 +19,7 @@
 #ifndef GDB_REGEX_H
 #define GDB_REGEX_H 1
 
-#ifdef USE_INCLUDED_REGEX
 # include "xregex.h"
-#else
-/* Request 4.2 BSD regex functions.  */
-# define _REGEX_RE_COMP
-# include <regex.h>
-#endif
 
 /* A compiled regex.  This is mainly a wrapper around regex_t.  The
    the constructor throws on regcomp error and the destructor is