Re: mlterm 3.9.2 Failed to open pty

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

On Thu, 21 Jul 2022 at 21:13:25 +0900, Rin Okuyama wrote:
> On 2022/07/21 19:23, RVP wrote:
> >    Looking at baselib/configure.in:279, the pty-type check programs
> >    only #include <fcntl.h> w/o pulling in <stdlib.h>. Depending on
> >    what pkgsrc's CFLAGS are, this could result in the 2 programs not
> >    compiling at all, and the configure thinking that only BSD ptys
> >    are present.
> >
> >    Hope this helps...
>
> Unfortunately no. It *does* builds only if O_RDWR and O_NOCTTY are
> defined. No matter whether posix_openpt(3) is declared or not.
>
> However, posix_openpt(O_RDWR | O_NOCTTY) returns -1 for some
> conditions. I've not reproduced this behavior for freshly-installed
> NetBSD/amd64 9.2.
>
> Maybe this is worth for PR...

The cause of the issue is that the package uses AC_RUN_IFELSE to check
if the posix_openpt(3) call *succeeds at runtime[1]*, not just if it
compiles and links. If the build environment is sandboxed, then the
call to open /dev/ptmx will fail, and the package will fall back to the
old "bsd" implementation instead.

The fix would be to remove the runtime check in the configure script,
if we want it reliably building in official (presumably sandboxed)
builds. I've had to do that in the past for other packages that did
something similar.

(I assume that's how the OP's issue arose, but I didn't see anything in
the thread about where mlterm is coming from, e.g., an official binary
package from NetBSD, or something built by the user in a sandboxed
environment, or something else. In any case, I can reproduce this in a
sandboxed pbulk environment, where it builds as expected outside of it,
so I investigated.)

I've also added a note to this effect in PR pkg/56936.

1. See baselib/configure.in starting at line 279

Regards,

Dave