[Patches] [ python-Patches-732284 ] UnixWare 7 build patch

[SourceForge.net]

Patches item #732284, was opened at 2003-05-04 20:58
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Rice (tim1470)
Assigned to: Nobody/Anonymous (nobody)
Summary: UnixWare 7 build patch

Initial Comment:
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


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2003-05-05 06:58

Message:
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.

----------------------------------------------------------------------

Comment By: Tim Rice (tim1470)
Date: 2003-05-04 23:59

Message:
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
--------------------------



----------------------------------------------------------------------

Comment By: Tim Rice (tim1470)
Date: 2003-05-04 22:09

Message:
Logged In: YES 
user_id=618097

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

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-05-04 21:15

Message:
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?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732284&group_id=5470