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.

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

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.

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.

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.

Logged In: YES 
user_id=21627

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

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.

Logged In: YES 
user_id=21627

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

Can you please try the attached patch?

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.

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.

Logged In: YES 
user_id=21627

Committed as

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

Logged In: YES 
user_id=487348

You can either have Python broken on every OpenBSD host (as
it is now) and feel good that you have a reason, or you can
take out the offending definitions, since that does indeed
fix the compilation of Python on all versions of OpenBSD
(confirmed for OpenBSD3.8 and Python2.4.2)