UnixWare 7 build patch

[tim1470]

BPO	732284
Nosy	@loewis
Files	uw7.patch: UnixWare build fixes uw7-2.patch: UnixWare 7 build fixes ver 2 uw7-correction.patch: corrections to configure.in uw7-correction.patch: corrections to configure.in

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2003-05-11.05:54:12.000>
created_at = <Date 2003-05-04.18:58:54.000>
labels = ['build']
title = 'UnixWare 7 build patch'
updated_at = <Date 2003-05-11.05:54:12.000>
user = 'https://bugs.python.org/tim1470'

bugs.python.org fields:

activity = <Date 2003-05-11.05:54:12.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2003-05-04.18:58:54.000>
creator = 'tim1470'
dependencies = []
files = ['5250', '5251', '5252', '5253']
hgrepos = []
issue_num = 732284
keywords = ['patch']
message_count = 10.0
messages = ['43628', '43629', '43630', '43631', '43632', '43633', '43634', '43635', '43636', '43637']
nosy_count = 2.0
nosy_names = ['loewis', 'tim1470']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue732284'
versions = ['Python 2.3']

[tim1470]

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

[loewis]

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?

[tim1470]

Logged In: YES
user_id=618097

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

[tim1470]

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

[loewis]

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.

[loewis]

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.

[loewis]

Logged In: YES
user_id=21627

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

[tim1470]

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.

[tim1470]

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.

[loewis]

Logged In: YES
user_id=21627

Thanks, applied as

configure 1.398
configure.in 1.409