`--without-termcap` in the OTP build scripts breaks tty support (raw mode, TUI apps) in Burrito binaries

[ryanwinchester]

The OTP builds published by beam-machine are configured with --without-termcap
(both compile_macos.sh and compile_linux_*.sh):

./configure --without-javac --without-jinterface --without-wx --without-termcap --without-megaco ...

That flag disables OTP's tty support entirely, so any Burrito-wrapped app that
needs an interactive terminal (OTP 28+ raw mode, TUI frameworks, anything
reading single keystrokes) does not work with the precompiled ERTS. This is
the root cause of burrito-elixir/burrito#215.

Symptoms

Probed from Application.start/2 of a wrapped app, run in a real terminal
(macOS arm64, OTP 29.0.5). Same launch arguments, only the ERTS differs:

probe	beam-machine ERTS	locally built OTP (termcap enabled)
:shell.start_interactive({:noshell, :raw})	{:error, :enotsup}	:ok
:io.columns() (after raw)	{:error, :enotsup}	{:ok, 80}
:io.get_chars(:standard_io, "", 1)	never returns	{:ok, "x"}
:io.getopts(:standard_io)	terminal: true (fds are ttys, but the tty backend is unavailable)	terminal: true

Pointing Burrito's custom_erts at a stock local OTP install fixes it with no
other changes, which isolates the problem to the published build configuration.

Suggested fix

Remove --without-termcap, keeping the builds portable:

• macOS: link the system ncurses — it ships with the OS, so a dynamic link
  is safe.
• Linux ("any" glibc/musl builds): statically link libtinfo/ncurses into
  the build, using the same pattern the scripts already use for OpenSSL
  (static build into the local sysroot, --with-ssl=... --disable-dynamic-ssl-lib).

Follow-ups this implies

• Already-published OTP versions would need re-building/re-uploading for the
  fix to reach existing Burrito users.
• Burrito's fetcher already cache-busts on openssl=/musl= versions
  (Burrito.Util.ERTSUniversalMachineFetcher.append_versions/0); a
  termcap=1/build-revision param (small burrito-side PR) would make clients
  re-download the rebuilt tarballs.

Related

• burrito-elixir/burrito#215 — the downstream report (raw mode :enotsup); its author independently confirmed a custom ERTS fixes it
• burrito-elixir/burrito#234 / #235 — a second, independent tty blocker in the 1.6.0 launcher (stdout piped through the wrapper); both need fixing for interactive apps to work end to end

[doawoo]

--without-termcap is needed to make the most portable ERTS possible, in my experience, trying to statically link libtinfo and ncurses results in a mess. You are free to compile or source your own ERTS tarball to ship with your app using the custom ERTS feature.

I don't intend on setting changing the termcap flag on the current provided builds, however.