mirror of
https://github.com/openwrt/packages.git
synced 2026-10-12 10:17:17 +04:00
Daniel Golle
6c1baacc1d
d883c02a41("python3: pin host curses to the SDK's narrow ncurses", 2026-05-28) forced every curses header check Python's configure.ac runs to "no", specifically to keep host ncurses's (then narrow-only) build from being shadowed by whatever curses headers the build host's own distro happened to ship under /usr/include. That assumption broke when openwrt/openwrt@18725c45a3 ("ncurses: bump to 6.6.20260801") switched host ncurses to track ncurses' git snapshots rather than the old 6.4 tarball: ncurses 6.6+ defaults to building wide-character support for ABI 6 (cf_dft_widec, gated on cf_cv_abi_default which is just the major version - this is a policy change accumulated in ncurses' own git history since 6.4 was tagged, not something OpenWrt or ncurses deliberately changed for wide-char specifically). Host ncurses now produces ncursesw.pc/panelw.pc, which Python 3.14's configure.ac finds independently via its own PKG_CHECK_MODULES(CURSES, ncursesw)-style pkg-config probe ("checking for ncursesw... yes") - a check that was never gated by these ac_cv_* overrides in the first place. That flips on the wide-character code paths in Modules/_cursesmodule.c, while the ac_cv_header_ncursesw_*=no overrides still force the *header* checks to fail, so the actual #include falls through to the stale narrow ncurses/ncurses.h. The result is a mismatch between what pkg-config says is available and what header actually got included, producing: ./Modules/_cursesmodule.c: error: implicit declaration of function 'unget_wch'; did you mean 'ungetch'? (and similarly for wget_wch, wins_nwstr, mvwins_nwstr - every wide-character-only curses function). Fix this at the python3/ncurses integration boundary rather than by touching ncurses' own host build behaviour globally (see openwrt/openwrt#24811, which tried --disable-widec on host ncurses and had to be reverted: it also drops extended colors from host tic, shrinking MAX_ENTRY_SIZE 32768->4096 so tic can no longer process the xterm/xterm-256color terminfo entries needed to assemble the target terminfo package). Since host ncurses's own -I.../include/ncursesw already gets added via pkg-config's Cflags substitution regardless of these overrides, stop forcing ac_cv_header_ncursesw_{ncurses,panel}_h to "no" - configure now genuinely finds ncursesw/ncurses.h in staging_dir/hostpkg, consistent with what its own pkg-config check already reports, and both detection paths agree. ac_cv_header_ncursesw_curses_h stays forced, along with the bare (non-w) curses.h/ncurses.h/panel.h checks: host ncurses is configured with --without-curses-h, so staging_dir/hostpkg/include/ncursesw/ has no curses.h of its own to genuinely detect - a real "yes" here could only ever come from the build host's own /usr/include/ncursesw/ curses.h (e.g. Fedora's ncurses-devel), the exact distro-shadowing this override block exists to prevent. Verified end to end: clean host python3 rebuild against unmodified current ncurses compiles Modules/_cursesmodule.c and Modules/_curses_panel.c without error, and the resulting staging_dir/hostpkg python3.14 successfully `import curses` with unget_wch present. Fixes:d883c02a41("python3: pin host curses to the SDK's narrow ncurses") Signed-off-by: Daniel Golle <daniel@makrotopia.org>