Okay, looks like my guess was correct. The diff at the end of this mail 
makes it work on OpenBSD/amd64 and it continues to work on i386, but it 
will probably break Linux (due to the problem it was working around 
mentioned in the comment at the beginning). I don't know enough about 
the Python build system to suggest a correct fix. (SUSv3 seems to 
suggest ioctl's request should be int, so perhaps OpenBSD is ultimately 
at fault.)

fcntl_ioctl in fcntlmodule.c seems to have some other potential 
problems on 64-bit archs too, as it seems to coerce the ioctl argument 
(potentially a pointer) into an int.

-- Nicholas.

--- fcntlmodule.c.orig	Tue Nov 20 09:39:12 2007
+++ fcntlmodule.c	Tue Nov 20 09:59:50 2007
@@ -101,7 +101,7 @@
 	   the signed int 'code' variable, because Python turns 
0x8000000
 	   into a large positive number (PyLong, or PyInt on 64-bit
 	   platforms,) whereas C expects it to be a negative int */
-	int code;
+	unsigned long code;
 	int arg;
 	int ret;
 	char *str;
@@ -109,7 +109,7 @@
 	int mutate_arg = 1;
  	char buf[IOCTL_BUFSZ+1];  /* argument plus NUL byte */
 
-	if (PyArg_ParseTuple(args, "O&Iw#|i:ioctl",
+	if (PyArg_ParseTuple(args, "O&Lw#|i:ioctl",
                              conv_descriptor, &fd, &code, 
 			     &str, &len, &mutate_arg)) {
 		char *arg;
@@ -160,7 +160,7 @@
 	}
 
 	PyErr_Clear();
-	if (PyArg_ParseTuple(args, "O&Is#:ioctl",
+	if (PyArg_ParseTuple(args, "O&Ls#:ioctl",
                              conv_descriptor, &fd, &code, &str, &len)) 
{
 		if (len > IOCTL_BUFSZ) {
 			PyErr_SetString(PyExc_ValueError,
@@ -182,7 +182,7 @@
 	PyErr_Clear();
 	arg = 0;
 	if (!PyArg_ParseTuple(args,
-	     "O&I|i;ioctl requires a file or file descriptor,"
+	     "O&L|i;ioctl requires a file or file descriptor,"
 	     " an integer and optionally an integer or buffer argument",
 			      conv_descriptor, &fd, &code, &arg)) {
 	  return NULL;