| msg13117 - (view) |
Author: Jon Ribbens (jribbens) * |
Date: 2002-11-07 15:57 |
| 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. |
|
|
| msg13118 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2002-11-09 19:09 |
| 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). |
|
|
| msg13119 - (view) |
Author: Jon Ribbens (jribbens) * |
Date: 2002-11-09 20:02 |
| 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. |
|
|
| msg13120 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-11-09 20:26 |
| 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. |
|
|
| msg13121 - (view) |
Author: Jon Ribbens (jribbens) * |
Date: 2002-11-09 20:44 |
| 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. |
|
|
| msg13122 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-11-09 21:27 |
| Logged In: YES user_id=21627 Ok, can you please report the ouput of 'uname -v' and 'uname -r' on your system? |
|
|
| msg13123 - (view) |
Author: Jon Ribbens (jribbens) * |
Date: 2002-11-09 22:43 |
| 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. |
|
|
| msg13124 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-11-09 23:47 |
| Logged In: YES user_id=21627 "All" BSD versions means 2.x, and 3.[012], right? Can you please try the attached patch? |
|
|
| msg13125 - (view) |
Author: Jon Ribbens (jribbens) * |
Date: 2002-11-11 02:16 |
| Logged In: YES user_id=76089 The patch nearly works. The line "if test definexopensource=yes"youhaveaddedtoconfigureshouldread"iftestdefine_xopen_source=yes" you have added to configure should read "if test definexopensource=yes"youhaveaddedtoconfigureshouldread"iftestdefine_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. |
|
|
| msg13126 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-11-11 06:01 |
| 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. |
|
|
| msg13127 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-11-11 13:30 |
| Logged In: YES user_id=21627 Committed as configure 1.355 configure.in 1.366 pyconfig.h.in 1.58 |
|
|
| msg13128 - (view) |
Author: Chuck Robey (chuckr11) |
Date: 2005-09-30 21:48 |
| 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) |
|
|