Serious side effect when building ncurses with pcre2

[Ken Gaillot]

Hi all,

I help maintain a project that uses both ncurses and the standard C
regex API. We stumbled into an issue during CI testing.

A distribution (OpenSUSE tumbleweed) built ncurses using the --with-
pcre2 option. Since we link against the ncurses library, this brought
libpcre2-posix into the libraries being linked to our project. Note
that the distribution did not install pcre2-posix as the system-wide
regex.h. (A bug has already been filed against the distribution for
this conflict.)

Since our project includes the standard regex.h rather than
pcre2posix.h, the values of various constants such as REG_NOMATCH were
different, and needless to say chaos ensues.

Since ncurses is a library intended for other applications' use, I
consider the possibility of requiring those applications to link
against libpcre2-posix (particularly since pkg-config will do so
silently) is a bug. (And a difficult one to troubleshoot!)

I'm not familiar with the ncurses code base, but some potential
alternatives off the top of my head:

* --with-pcre2 could have a loud warning about the potential conflict.

* --with-pcre2 could check regex.h for pcre2-specific symbols and
disallow the option if not present. (Downside: someone could replace
regex.h after ncurses is built.)

* ncurses could use the pcre2 library/APIs that do not step on the
standard APIs (libpcre2-8 and whatnot) when --with-pcre2 is given.

Thanks for your time,
-- 
Ken Gaillot <kgaillot@redhat.com>