[Python-bugs-list] [ python-Bugs-635034 ] Don't define _XOPEN_SOURCE on OpenBSD
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 10 Nov 2002 18:16:01 -0800
Bugs item #635034, was opened at 2002-11-07 15:57
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't define _XOPEN_SOURCE on OpenBSD
Initial Comment:
Defining _XOPEN_SOURCE on OpenBSD breaks many
things. For example, it makes the select and time
modules unavailable (*oops*).
I think this is probably a bug in OpenBSD (I have
bugreported it there) but in the absence of the ability to
fix the bug in every OpenBSD installation in the world it
would be nice if Python would detect OpenBSD and not
define _XOPEN_SOURCE.
----------------------------------------------------------------------
>Comment By: Jon Ribbens (jribbens)
Date: 2002-11-11 02:16
Message:
Logged In: YES
user_id=76089
The patch nearly works. The line "if test
$define_xopen_source=yes" you have added to configure
should read "if test $define_xopen_source = yes" (i.e. with
spaces around the equals sign).
With the patch, amended, it fixes the problem. Please though
could you change it to 'OpenBSD/*' instead of 'OpenBSD/2.*'
and 'OpenBSD/3.[012]'?
I think it is much more likely to cause problems in the future
that _XOPEN_SOURCE *is* defined in the as-yet-
hypothetical OpenBSD/3.3 than if it were not defined since I
don't suspect that OpenBSD will suddenly start requiring
people to define this value that would break compatibility with
all older OpenBSDs ;-)
Many thanks.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-11-09 23:47
Message:
Logged In: YES
user_id=21627
"All" BSD versions means 2.x, and 3.[012], right?
Can you please try the attached patch?
----------------------------------------------------------------------
Comment By: Jon Ribbens (jribbens)
Date: 2002-11-09 22:43
Message:
Logged In: YES
user_id=76089
Umm, ok... Why is this useful? ;-)
$ uname -r
2.7
$ uname -v
SNOWY#0
If you're wanting to detect OpenBSD surely it's that "uname -
s" == "OpenBSD"? Like I say so far as I can tell it's *all*
versions of OpenBSD that have the problem.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-11-09 21:27
Message:
Logged In: YES
user_id=21627
Ok, can you please report the ouput of 'uname -v' and 'uname
-r' on your system?
----------------------------------------------------------------------
Comment By: Jon Ribbens (jribbens)
Date: 2002-11-09 20:44
Message:
Logged In: YES
user_id=76089
Don't be irritating. Of course the header files don't change, but
through the use of #if statements what they do *does*
change. My statement is perfectly correct, the definitions are
indeed still there but they are "not available" like I said.
Here is a URL for the very latest sys/types.h:
http://www.openbsd.org/cgi-
bin/cvsweb/~checkout~/src/sys/sys/types.h?
rev=1.18&content-type=text/plain
Search for "fd_set". You will see that it is in a #if section as
follows:
#if !defined(_POSIX_SOURCE) && !defined
(_XOPEN_SOURCE)
select() itself comes from unistd.h, and is inside:
#if !defined(_XOPEN_SOURCE)
No, I don't know why these #if statements are there, they
seem completely stupid, but there we go.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-11-09 20:26
Message:
Logged In: YES
user_id=21627
Your statement "are simply not available in any header
file" is factually incorrect: none of the header files
change on disk by defining something, so the definitions are
still in the header files. Can you please attach the header
file that normally carries select?
> Why is _XOPEN_SOURCE being defined anyway?
Because many systems require it, for conformance. POSIX
mandates that you define it, if you want to use system
interface that are specified by more recent POSIX releases, see
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html
In particular, many features of HP-UX are not available
unless you define _XOPEN_SOURCE, the same holds for the
various SCO Unices.
----------------------------------------------------------------------
Comment By: Jon Ribbens (jribbens)
Date: 2002-11-09 20:02
Message:
Logged In: YES
user_id=76089
It would be a great deal of effort to make separate bug reports
(I would have to individually test every Python feature by
hand), and it wouldn't gain anything.
The problem is that OpenBSD is buggy, has been since
version 2.0 and still is in the very latest CVS. For example, if
you define _XOPEN_SOURCE (its value doesn't make any
difference, just if it is defined) then there is absolutely no way
to get the select(), fd_set, etc, they are simply not available
in any header file. You can't use select() in a C program that
#defines _XOPEN_SOURCE.
I don't see why you say there is "no way" to withdraw the
definition of _XOPEN_SOURCE - instead of making the
addition of _XOPEN_SOURCE to the header file
unconditional, simply detect OpenBSD in ./configure and
don't define it in that case. Why is that difficult?
Why is _XOPEN_SOURCE being defined anyway? Because
it breaks everything so badly on OpenBSD, and nobody has
noticed this before, I am suspecting that almost no programs
out there except Python define it. This makes it likely to
break things on many different platforms.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-11-09 19:09
Message:
Logged In: YES
user_id=21627
You need to provide more details. For the moment, I see *no
way* to withdraw the definition of _XOPEN_SOURCE, not even
for OpenBSD.
Please make separate bug reports for each issue, perhaps
starting with the select module. Why is it unavailable?
select *is* a feature of POSIX, after all (as is poll).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=635034&group_id=5470