Don't define _XOPEN_SOURCE on OpenBSD

[jribbens]

BPO	635034
Nosy	@loewis, @jribbens
Files	bsd.diff

^{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 2005-09-30.21:48:11.000>
created_at = <Date 2002-11-07.15:57:07.000>
labels = ['library']
title = "Don't define _XOPEN_SOURCE on OpenBSD"
updated_at = <Date 2005-09-30.21:48:11.000>
user = 'https://github.com/jribbens'

bugs.python.org fields:

activity = <Date 2005-09-30.21:48:11.000>
actor = 'chuckr11'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2002-11-07.15:57:07.000>
creator = 'jribbens'
dependencies = []
files = ['666']
hgrepos = []
issue_num = 635034
keywords = []
message_count = 12.0
messages = ['13117', '13118', '13119', '13120', '13121', '13122', '13123', '13124', '13125', '13126', '13127', '13128']
nosy_count = 3.0
nosy_names = ['loewis', 'jribbens', 'chuckr11']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue635034'
versions = ['Python 2.3']

[jribbens]

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.

[loewis]

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

[jribbens]

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.

[loewis]

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.

[jribbens]

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.

[loewis]

Logged In: YES
user_id=21627

Ok, can you please report the ouput of 'uname -v' and 'uname
-r' on your system?

[jribbens]

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.

[loewis]

Logged In: YES
user_id=21627

"All" BSD versions means 2.x, and 3.[012], right?

Can you please try the attached patch?

[jribbens]

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.

[loewis]

Logged In: YES
user_id=21627

I won't implement a blanket change for all future OpenBSD
versions. I don't expect that OpenBSD will *require*
definition of _XOPEN_SOURCE, either, but I do hope that they
provide a mechanism to request extensions some day. So this
change will need to be re-evaluated for each OpenBSD release.

I hope that Python can remove all these system-specific
changes, over time. This can't happen until we stop support
OpenBSD 3.2, but we do need to record what versions of
OpenBSD are affected, and we do need actual proof that they
are affected, and that no alternative solution is available.

[loewis]

Logged In: YES
user_id=21627

Committed as

configure 1.355
configure.in 1.366
pyconfig.h.in 1.58