On Sun, 20 Mar 2011, Mònica Ramírez Arceda wrote:
El dv 18 de 03 de 2011 a les 23:14 -0400, en/na Benjamin Kaduk va
escriure:
On Fri, 18 Mar 2011, Mats Erik Andersson wrote:
fredag den 18 mars 2011 klockan 21:34 skrev Petr Salinger detta:
I mantain splitvt and the last release fails to build on kfreebsd-i386
[0] and on kfreebsd-amd64 [1]. This problem is reported here [2].
Any help with this would be very appreciated :-)
Port it to POSIX <termios.h> ?
The splitvt already supports termio,
so basically convert
ioctl(fd, TCGETA, (char *) &tty_mode)
into
tcgetattr(fd, tty_mode)
[...]
Going back to the package itself, a manually
inserted "-DCOMPAT_43TTY" in the makefile
will allow all binaries to compile. Whether
they act correctly remains to be tested.
COMPAT_43TTY is a kernel option. Per
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/amd64/conf/GENERIC?rev=1.541;content-type=text%2Fx-cvsweb-markup
it is removed from stock FreeBSD kernel for a year, now; it seems to not
be in patches/ for kfreebsd image, so correct functionality is highly
unlikely.
splitvt tries to use sys/ioctl_compat.h:
---splitvt/config.c---
139 /* Check for ioctl compatibility. (FreeBSD) */
140 if ( exists(INCLUDE, "sys/ioctl_compat.h") ) {
141 strcat(cflags, " -DNEED_COMPAT_H");
142 VERBOSE_PRINT(
143 "\tI will use your ioctl compatibility header.\n");
144 }
------
If this is all the checking it is doing, that is something like a bug. A
proper check (autoconf-style) would compile a stub binary that attempts to
actually call ioctl() with the parameters which require the compatibility
stubs (e.g. TIOCLSET), and use the compatibility header if that stub
binary compiled successfully...
(The fact that this is in a .c source file makes me rather sympathetic to
not doing so, though.)
But in sys/ioctl_compat.h [0]:
---sys/ioctl_compat.h---
41 #ifndef COMPAT_43TTY
42 #error "Definitions not available without TTY ioctl compat."
43 #endif
------
... because this line means that the header can be present but useless.
ioctl() is a userland-kernel interface, and userland must ensure that it
is using an API/ABI that is supported by the running kernel. If 'options
COMPAT_43TTY' is not present in the kernel configuration file, attempts to
use these compatibility interfaces with ioctl() will fail with ENOIOCTL
[1].
/usr/include/sys/opt_compat.h will #define COMPAT_43TTY if this support is
in the kernel (though I do not believe it is correct usage for a userland
program to include this header directly); defining it manually is
essentially guaranteed to do the wrong thing except in strange edge cases.
It seems "-DCOMPAT_43TTY" solution could be a good one but if it is
removed... What happens with sys/ioctl_compat.h?
Also, I can try the first solution and port to POSIX <termios.h>,
altough there are quite a lot of ioctl calls.
It seems that this is the only real solution available to you, as using
the compatibility routines would require almost all of your users to
compile a custom kernel.
-Ben Kaduk
[1] http://fxr.watson.org/fxr/source/kern/tty.c#L1698
Thanks a lot for your help!
Mònica
[0] http://fxr.watson.org/fxr/source/sys/ioctl_compat.h
