Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IO-Tty-1.18 does not work on FreeBSD 14 #38

Open
abqcheeks opened this issue Dec 19, 2023 · 4 comments
Open

IO-Tty-1.18 does not work on FreeBSD 14 #38

abqcheeks opened this issue Dec 19, 2023 · 4 comments
Assignees

Comments

@abqcheeks
Copy link

abqcheeks commented Dec 19, 2023

I haven't tested on different FreeBSD versions, but I have tested on two different FreeBSD 14 systems, one with 1.17 (from packages) and one with 1.18 (from ports).

The symptom is it installs but can't open any ptys. This test program demonstrates it:

#!/usr/local/bin/perl
use IO::Pty;
$mpty = IO::Pty->new;

In the broken state, truss indicates it's trying to open lots of pty variations that don't exist:

openat(AT_FDCWD,"/dev/ptyp0151",O_RDWR|O_NOCTTY,00) ERR#2 'No such file or directory'
openat(AT_FDCWD,"/dev/ptyto",O_RDWR|O_NOCTTY,00) ERR#2 'No such file or directory'
openat(AT_FDCWD,"/dev/ptyp152",O_RDWR|O_NOCTTY,00) ERR#2 'No such file or directory'
openat(AT_FDCWD,"/dev/pt/to",O_RDWR|O_NOCTTY,00) ERR#2 'No such file or directory'
openat(AT_FDCWD,"/dev/ptyp0152",O_RDWR|O_NOCTTY,00) ERR#2 'No such file or directory'
openat(AT_FDCWD,"/dev/ptytp",O_RDWR|O_NOCTTY,00) ERR#2 'No such file or directory'

And then pty_allocate() returns nothing.

Comparing build output from 1.17 and 1.18 shows the build process is not finding a lot of needed functions.

Building 1.17 (cd /usr/ports/devel/p5-IO-Tty ; make) the following functions are found:

Looking for _getpty()...... not found.
Looking for getpt()........ not found.
Looking for grantpt()...... FOUND.
Looking for openpty()...... FOUND.
Looking for posix_openpt(). FOUND.
Looking for ptsname()...... FOUND.
Looking for ptsname_r().... FOUND.
Looking for sigaction().... FOUND.
Looking for strlcpy()...... FOUND.
Looking for ttyname()...... FOUND.
Looking for unlockpt()..... FOUND.
Looking for libutil.h...... FOUND.
Looking for pty.h.......... not found.
Looking for sys/pty.h...... not found.
Looking for sys/ptyio.h.... not found.
Looking for sys/stropts.h.. not found.
Looking for termio.h....... not found.
Looking for termios.h...... FOUND.
Looking for util.h......... not found.

Doing the same with 1.18:

Looking for getpt()........ not found.
Looking for grantpt()...... not found.
Looking for openpty()...... not found.
Looking for posix_openpt(). not found.
Looking for ptsname()...... not found.
Looking for ptsname_r().... not found.
Looking for sigaction().... not found.
Looking for strlcpy()...... not found.
Looking for ttyname()...... not found.
Looking for unlockpt()..... not found.
Looking for libutil.h...... FOUND.
Looking for pty.h.......... not found.
Looking for sys/pty.h...... not found.
Looking for sys/ptyio.h.... not found.
Looking for sys/stropts.h.. not found.
Looking for termio.h....... not found.
Looking for termios.h...... FOUND.
Looking for util.h......... not found.

I'm happy to test any fixes.

@toddr
Copy link
Member

toddr commented Dec 28, 2023

Can you tell me if 1.19 fixes your issue?

@abqcheeks
Copy link
Author

abqcheeks commented Dec 28, 2023

Can you tell me if 1.19 fixes your issue?

Yes and no. I retrieved 1.20 and tried it with the FreeBSD ports skeleton for p5-IO-Tty and it had the same problem ("perl Makefile.PL" step doesn't find openpty() and friends).

The ports skeleton has a patch for Makefile.PL which changes line 149 from:
char (*f) ();
To:
char f;

If I back out that change, then 1.20 builds and works OK. I now suspect if I backed out that change 1.18 might also work but I haven't tried it.

I guess we need to raise this with the maintainer of the port.

@abqcheeks abqcheeks reopened this Dec 28, 2023
@toddr
Copy link
Member

toddr commented Dec 29, 2023

The change that broke you is from 1735a78 related to #23 and #33. I'll look closer at it later tonight. Might just need to back it out as it's caused more harm than good.

@davehayes
Copy link

davehayes commented Apr 1, 2024

I'm just confirming the discovery of this same behavior on FreeBSD 13.2-STABLE. However this seems related to this issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276535

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants