Bug report

configure decides whether to build the curses module wide (HAVE_NCURSESW, the cchar_t API) from the pkg-config name: ncursesw is wide, ncurses is narrow. But wide-character support is a property of the library, not of its name. An ncurses built with --enable-widec that keeps the plain libncurses/ncurses.pc name is built narrow though it is fully wide-capable. This happens with pkgsrc ncurses (NetBSD, illumos and others) and with the system ncurses of macOS.

A narrow build against a wide library loses functionality. The wide API (get_wch(), add_wch(), complexchar, ...) is not built at all. And the character-based API (addch(), getch(), inch(), getbkgd(), ...) handles only ASCII in multibyte locales such as UTF-8, which are now the norm; the single-byte 8-bit locales in which it works fully are rare today.

configure already probes the wide API (setcchar()/add_wch()) for the native curses backend (gh-136687). Running that probe for the ncurses/auto backends too, and defining HAVE_NCURSESW from the probe result rather than from the name, builds wide whenever the library supports it.

On macOS, where the default locale is UTF-8, the narrow build is almost unusable, so this is a bugfix as much as an improvement: curses moves from a narrow build to a wide one. The system ncurses is wide-capable and the existing Darwin block already adds -D_XOPEN_SOURCE_EXTENDED reaching for wide, so this completes that intent.

Linked PRs

Linked PRs

• gh-154070: Build the curses module wide by capability, not by name #154071
• [3.15] gh-154070: Build the curses module wide by capability, not by name (GH-154071) #154765
• [3.14] gh-154070: Build the curses module wide by capability, not by name (GH-154071) (GH-154765) #154799
• [3.13] gh-154070: Build the curses module wide by capability, not by name (GH-154071) (GH-154765) #154800