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