ycurses: get it building on modern GCC, verify in Docker (task 9s0)

ycurses shares no source files with ychat/yhttpd (it's an ncurses UI
toolkit, not part of the httpd/socket engine), so none of the sock/reqp/
html/logd/tool fixes apply here - only the same class of toolchain-gate
bugs did:

- Top-level configure's g++ 3.x version gate now accepts any GNU g++
  (same fix as yhttpd/configure).
- scripts/config.pl silently BEGIN-failed on modern Perl (`use
  scripts::modules::file` needs "." on @INC, dropped by Perl 5.26+); the
  "yes" default answer was never actually read. Fixed with `perl -I.`
  (also applied to yhttpd/configure, which had the same latent bug).
- src/configure's library search paths predate 64-bit multilib distros
  (no /usr/lib64), so installed libpanel/libmenu/libncurses were reported
  "NOT OK" on Rocky Linux 9 (also backported to yhttpd/src/configure).
- attributes.h declared `set<int> set_attr` (std::set, via `using
  namespace std`) and separately two member functions literally named
  `set` - GCC 11 treats that as ill-formed ("changes meaning of 'set'"),
  not just a warning. Renamed both overloads to set_attr_flag; no
  external caller used the bare set(...)/set(int) names.

Verified in a Rocky Linux 9 container: builds clean, links, and runs -
initializes curses, draws the demo screen using color/attributes
(exercising the fix above), exits cleanly. Added Dockerfile (build
verification only - it's an interactive demo, not a service) and
BUILD.md documenting the fixes and one pre-existing, deliberately
unfixed bug (unset() never actually clears an attribute).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

1 files changed, 66 insertions, 0 deletions

diff --git a/ycurses/BUILD.md b/ycurses/BUILD.md
new file mode 100644
index 0000000..809c39d
--- /dev/null
+++ b/ycurses/BUILD.md
@@ -0,0 +1,66 @@
+# ycurses — build revival
+
+`ycurses` is a standalone ncurses C++ toolkit (windows, menus, attributes,
+color) from the same ~2003-2005 era as `../ychat` and `../yhttpd`, but it
+shares no source files with them (no `sock`/`reqp`/`html`/`logd`/`tool`) -
+it's a UI library, not a network daemon. `src/main.cpp` is an interactive
+full-screen demo menu; there is no service to deploy, so unlike `../yhttpd`
+this only needed a build fix, verified in Docker (`Dockerfile` here is a
+build check, not a runtime image).
+
+## Build & verify (local)
+
+```
+podman build -t ycurses:dev .
+podman run --rm -it ycurses:dev   # interactive demo menu; Ctrl-C to exit
+```
+
+Verified: builds clean (one pre-existing, harmless `-Wreturn-type` warning
+in `menu.cpp`), links, and runs - initializes curses, draws the demo screen
+using `color`/`attributes` (exercising the fix below), exits cleanly on
+EOF/SIGINT.
+
+## What was fixed
+
+- **Top-level `configure`'s g++ 3.x version gate** now accepts any GNU g++
+  (was hardcoded to versions 3.1-3.4), same fix as `../yhttpd/configure`.
+- **`scripts/config.pl` silently failed on modern Perl**: it does `use
+  scripts::modules::file`, which needs `.` on `@INC`; Perl 5.26+ dropped
+  `.` from the default `@INC`. The top-level `configure` invoked it via
+  `system("perl ...")` without `-I.`, so it `BEGIN`-failed before ever
+  reading the "yes" answer - harmless here only because the committed
+  `src/glob.h` defaults already matched, but it means the interactive
+  configurator never actually ran. Fixed with `perl -I.` (also applied to
+  `../yhttpd/configure`, which has the same bug).
+- **`src/configure`'s library search path list predates 64-bit multilib
+  distros**: it only checked `/usr/lib`, `/lib`, etc., never `/usr/lib64`
+  or `/lib64`, so `libpanel.so`/`libmenu.so`/`libncurses.so` were reported
+  "NOT OK" on Rocky Linux 9 even though they're installed - the script
+  aborts before generating a Makefile if a required lib "isn't found" (the
+  actual compiler/linker would have found them fine via its own default
+  search path; this is purely the custom dependency-checker being
+  outdated). Added `/lib64`, `/usr/lib64`, `/usr/local/lib64` to
+  `@libpaths` (also applied to `../yhttpd/src/configure` for the same
+  latent gap, even though yhttpd doesn't currently need any of these
+  libs).
+- **`attributes` class member functions named `set`/`set(int)` collide
+  with `std::set`**: `attributes.h` does `using namespace std` and declares
+  `set<int> set_attr` (a `std::set`), then separately declares member
+  *functions* literally named `set` - GCC 11 treats declaring a member
+  with the same name as a using-directive-visible type as ill-formed
+  ("changes meaning of 'set'"), not just a warning. Renamed both
+  overloads to `set_attr_flag` (`attributes.h`, `attributes.cpp`); no
+  external caller used the bare `set(...)`/`set(int)` names (checked all
+  of `src/`), only the named setters (`set_bold`, etc.) and the unrelated
+  `window::set_attributes`. Same category of fix as the
+  `function`->`mod_func_t` rename in `../ychat`/`../yhttpd`'s `glob.h`.
+
+## Known pre-existing issue (not fixed - out of scope for this pass)
+
+`attributes::set_attr_flag(bool b, int i_attr)` (`attributes.cpp`) never
+actually removes a flag when `b` is `false`: it only checks whether the
+current membership already equals `b` and, if not, unconditionally
+**inserts** into `set_attr` - so `unset(...)` cannot clear an attribute
+once set (it either no-ops or wrongly re-inserts). This bug predates this
+revival and is unrelated to the build/toolchain fixes above; flagging it
+here rather than fixing it silently while touching this function.