Here is a patch to fix the build on UnixWare 7 &
OpenUNIX 8 without
taking the simple route of  define_xopen_source=no.
This patch depends on patches 731191 and 732234

Logged In: YES 
user_id=21627

Is there absolutely no way to get to these types when
_XOPEN_SOURCE is defined? Not by including some obscure
header file? Not by defining some obscure macro?

Logged In: YES 
user_id=618097

There may be a way
Hold off until I test defining _POSIX_SOURCE

Logged In: YES 
user_id=618097

If I define _POSIX_SOURCE the data types are available but I
get a whole new
set of errors in posixmodule.c
....
cc -Kthread -K pentium,host,inline,loop_unroll,alloca
-DNDEBUG -O -I.
-I/opt/src/utils/python/python/dist/src/Include 
-DPy_BUILD_CORE  -c
/opt/src/utils/python/python/dist/src/Modules/posixmodule.c
-o Modules/posixmodule.o
UX:acomp: ERROR: "/usr/include/sys/wait.h", line 141: Syntax
error before or at: siginfo_t
UX:acomp: WARNING:
"/opt/src/utils/python/python/dist/src/Modules/posixmodule.c",
line 874: improper member use: tv_nsec
UX:acomp: WARNING:
"/opt/src/utils/python/python/dist/src/Modules/posixmodule.c",
line 875: improper member use: tv_nsec
UX:acomp: WARNING:
"/opt/src/utils/python/python/dist/src/Modules/posixmodule.c",
line 876: improper member use: tv_nsec
gmake: *** [Modules/posixmodule.o] Error 1
....

I'm attaching a new patch that has the data type checks from
patch 731991.
With this patch (which still depends on patches 731991 &
732234) UnixWare 7
builds. It's kind of ugly and I don't like it much. 
The simple alternative is to use this patch
--------------------------
--- configure.in.old    2003-04-17 13:16:42.000000000 -0700
+++ configure.in        2003-04-22 15:26:13.450080095 -0700
@@ -124,6 +124,8 @@
   # of union __?sigval. Reported by Stuart Bishop.
   SunOS/5.6)
     define_xopen_source=no;;
+  OpenUNIX/8.* | UnixWare/7.*)
+    define_xopen_source=no;;
 esac

 if test $define_xopen_source = yes
--------------------------

Logged In: YES 
user_id=21627

When I asked "is there no way to get these types", I didn't
expect that the answer would be "sure, Python can define
them itself". By that approach, you wouldn't need any system
headers, but could include any declaration literally in
Python, with #ifdef UW7. This is clearly not the right
solution: I meant to ask "is there no way to get these types
*from the system headers*"

If the answer to that question is "no", then I'm still
curious what the answer to the question "Why *specifically*
do we need u_int in the first place?" is. By "specifically",
I mean what *specific* other declaration from the system
headers relies on it, saying that sys/socket.h needs it is
too general.

I'm willing to go with the simple patch, provided it is
changed in the following way:
1. A comment is added indicating what the specific reason
for this patch is.
2. The system check is strengthened to not include future
system releases. I.e. saying OpenUNIX/8.*|UnixWare/7.* is
too generic: include a list of minor system releases so far.

Logged In: YES 
user_id=21627

I have now disabled _XOPEN_SOURCE in

configure 1.396
configure.in 1.407

I have used the information provided in 731991, and assumed
that the patch is necessary for UnixWare 7.1.[123], where
7.1.2 identifies itself as OpenUNIX 8.0.

Logged In: YES 
user_id=21627

Assuming it all works now fine, I'm closing this patch.

Logged In: YES 
user_id=618097

Thanks for the changes so far.
Actually OpenUNIUX identifies iteslf a 8.0.0 I'm attaching a
patch that
corrects this as well as allowing UnixWare 7.1.0 through 7.1.3.
I've also added SCO OpenServer to the define_xopen_source=no
list as it
has the same problems of missing data types. Your comments
in configure.in
about UnixWare 7 actually fit OpenServer perfectly. I've
updated the 
UnixWare 7 comments.

Logged In: YES 
user_id=618097

Thanks for the changes so far.
Actually OpenUNIUX identifies iteslf a 8.0.0 I'm attaching a
patch that
corrects this as well as allowing UnixWare 7.1.0 through 7.1.3.
I've also added SCO OpenServer to the define_xopen_source=no
list as it
has the same problems of missing data types. Your comments
in configure.in
about UnixWare 7 actually fit OpenServer perfectly. I've
updated the 
UnixWare 7 comments.

Logged In: YES 
user_id=21627

Thanks, applied as

configure 1.398
configure.in 1.409