How do I build Python 2.3.4 on OpenBSD 3.5?

[Noah]

I'm getting configure warnings and make errors when I try to
build Python 2.3.4 under OpenBSD 3.5. I don't see anything in the
README under "Platform specific note" for OpenBSD. I tried
opening the Python tar file using gtar and I tried using gmake
just to make sure there wasn't anything weird going on there
(I know that using BSD tar when building Zope used to cause
problems, so I first thought I might be having a similar problem.
I'm using gcc version 2.95.3 20010125 (prerelease, propolice).
That's the default that comes with OpenBSD. I didn't change anything.

Has anyone else had similar problems?
I'd appreciate any advice. Hopefully this is a simple mistake...

Here is a clip of the configure warnings that I get:
configure: WARNING: ncurses.h: present but cannot be compiled
configure: WARNING: ncurses.h: check for missing prerequisite
headers?
configure: WARNING: ncurses.h: proceeding with the preprocessor's
result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bu**********@gnu.org. ##
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: sys/audioio.h: present but cannot be compiled
configure: WARNING: sys/audioio.h: check for missing prerequisite
headers?
configure: WARNING: sys/audioio.h: proceeding with the preprocessor's
result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bu**********@gnu.org. ##
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: sys/lock.h: present but cannot be compiled
configure: WARNING: sys/lock.h: check for missing prerequisite
headers?
configure: WARNING: sys/lock.h: proceeding with the preprocessor's
result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bu**********@gnu.org. ##
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: sys/select.h: present but cannot be compiled
configure: WARNING: sys/select.h: check for missing prerequisite
headers?
configure: WARNING: sys/select.h: proceeding with the preprocessor's
result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to bu**********@gnu.org. ##
configure: WARNING: ## ------------------------------------ ##

Here is what I see when I try make:
bash-2.05b# gmake
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o
Modules/python.o Modules/python.c
In file included from /usr/include/sys/select.h:38,
from Include/pyport.h:118,
from Include/Python.h:48,
from Modules/python.c:3:
/usr/include/sys/event.h:53: syntax error before `u_int'
/usr/include/sys/event.h:55: syntax error before `u_short'
gmake: *** [Modules/python.o] Error 1

Here is a clip from the config.log file showing the error for select:
configure:4697: checking sys/select.h usability
configure:4710: gcc -c -g -O2 conftest.c >&5
In file included from /usr/include/sys/select.h:38,
from configure:4773:
/usr/include/sys/event.h:53: syntax error before `u_int'
/usr/include/sys/event.h:55: syntax error before `u_short'
configure:4713: $? = 1
configure: failed program was:
| #line 4699 "configure"
| /* confdefs.h. */
|
Yours,
Noah

[Martin v. Löwis]

Noah wrote:

Has anyone else had similar problems?
I'd appreciate any advice. Hopefully this is a simple mistake...

OpenBSD does not support Python, so Python has to work around.
However, the OpenBSD work-around is only in force for versions
up to OpenBSD 3.4. In configure, locate the place where it
talks about OpenBSD; then add a 5 to the place that already
lists 234.

Regards,
Martin

[Noah]

"Martin v. Löwis" <ma****@v.loewis.de> wrote in message news:<41***********************@news.freenet.de>.. .

OpenBSD does not support Python, so Python has to work around.
However, the OpenBSD work-around is only in force for versions
up to OpenBSD 3.4. In configure, locate the place where it
talks about OpenBSD; then add a 5 to the place that already
lists 234.

Regards,
Martin

Is it more correct to say that Python does not support OpenBSD?
It seems like the language should support the OS and not the other way around.
What limitations are there for Python on OpenBSD? What work-arounds does
Python have to take? It looks like it undefines _XOPEN_SOURCE.
Does this limit features on OpenBSD?

Should it be a bug that configure doesn't also do this for OpenBSD 3.5?
Although Python 2.3.4 came out before OpenBSD 3.5.

Thanks for the tip. This fixed everything and it builds fine now.

Yours,
Noah

[Martin v. Löwis]

Noah wrote:

Is it more correct to say that Python does not support OpenBSD?
It seems like the language should support the OS and not the other way around.
People usuall think that way, yes. However, in this case, it is really
the other way 'round. OpenBSD claims to implement certain
specifications required by Python, but then actually doesn't. Python
could accept systems that make no such claim, or systems that make
the claim and then fully implement the specification (POSIX in this
case). OpenBSD falls in the middle category of systems making false
or confusing claims.
What limitations are there for Python on OpenBSD? What work-arounds does
Python have to take? It looks like it undefines _XOPEN_SOURCE.
Does this limit features on OpenBSD?
No, it (wrongly) exposes them. OpenBSD "honors" _XOPEN_SOURCE, but
incorrectly. If you define _XOPEN_SOURCE on OpenBSD (which one is
entitled to do on any POSIX system), then some system headers fail
to compile. It would be fine if the system headers offered less
functionality in that case, or more - in no case they should stop
to compile. Python requires that systems either totally ignore
_XOPEN_SOURCE, or honor it by reacting accordingly. Failure to
compile is not a proper reaction.

Many systems currently have the similar flaws, since nobody dares
defining _XOPEN_SOURCE. Since Python needs to define _XOPEN_SOURCE
on some systems (most notably Tru64), and it is "the right thing"
on any system claiming POSIX conformance, and should not hurt on
all other systems, Python defines it always, and exempts a few
specific systems which are known to be broken.

Some vendors have acted since and fixed their systems, e.g. Sun
with Solaris 7 and later. Others, like the OpenBSD maintainers,
unfortunately fail to do so to date.
Should it be a bug that configure doesn't also do this for OpenBSD 3.5?
Although Python 2.3.4 came out before OpenBSD 3.5.

Right. Furthermore, we do hope that some OpenBSD release will fix that
bug. Then, we can gradually remove the work-arounds for older BSD
releases when these systems come out of use. For that procedure,
we need to check every OpenBSD release again whether it supports
POSIX properly.

I just recently added a change to Python 2.4 so it extends the
work-around for 3.5, so Python 2.4 should build on OpenBSD 3.5
out of the box.

Regards,
Martin