Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.4.1 build fails on OpenBSD 3.7 #42217

Closed
lpd mannequin opened this issue Jul 25, 2005 · 8 comments
Closed

2.4.1 build fails on OpenBSD 3.7 #42217

lpd mannequin opened this issue Jul 25, 2005 · 8 comments
Labels
build The build process and cross-build

Comments

@lpd
Copy link
Mannequin

lpd mannequin commented Jul 25, 2005

BPO 1244610
Nosy @loewis, @hyeshik

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 2006-01-09.07:11:19.000>
created_at = <Date 2005-07-25.16:31:34.000>
labels = ['build']
title = '2.4.1 build fails on OpenBSD 3.7'
updated_at = <Date 2006-01-09.07:11:19.000>
user = 'https://bugs.python.org/lpd'

bugs.python.org fields:

activity = <Date 2006-01-09.07:11:19.000>
actor = 'nnorwitz'
assignee = 'nnorwitz'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2005-07-25.16:31:34.000>
creator = 'lpd'
dependencies = []
files = []
hgrepos = []
issue_num = 1244610
keywords = []
message_count = 8.0
messages = ['25855', '25856', '25857', '25858', '25859', '25860', '25861', '25862']
nosy_count = 5.0
nosy_names = ['loewis', 'nnorwitz', 'lpd', 'hyeshik.chang', 'jp3g']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1244610'
versions = ['Python 2.4']

@lpd
Copy link
Mannequin Author

lpd mannequin commented Jul 25, 2005

Python 2.4.1, OpenBSD 3.7, gcc (GCC) 3.3.5 (propolice).

I'm including the logs here because they are short.

"./configure" printed the following:

checking curses.h usability... no
checking curses.h presence... yes
configure: WARNING: curses.h: present but cannot be
compiled
configure: WARNING: curses.h: check for missing
prerequisite headers?
configure: WARNING: curses.h: see the Autoconf
documentation
configure: WARNING: curses.h: section "Present But
Cannot Be Compiled"
configure: WARNING: curses.h: proceeding with the
preprocessor's result
configure: WARNING: curses.h: in the future, the
compiler will take precedence
configure: WARNING: ##
------------------------------------------------ ##
configure: WARNING: ## Report this to
http://www.python.org/python-bugs ##
configure: WARNING: ##
------------------------------------------------ ##
checking for curses.h... yes

This warning was printed for curses.h, ncurses.h,
sys/audioio.h, and sys/lock.h. (The reference to
"Autoconf documentation" is useless, because autoconf
is not used during the configure process, and is not
even installed on the system where I was doing the
build.) Then:

% make
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:116,
from Include/Python.h:55,
from Modules/python.c:3:
/usr/include/sys/event.h:53: error: syntax error before
"u_int"
/usr/include/sys/event.h:55: error: syntax error before
"u_short"
*** Error code 1

Stop in /usr/src/Python-2.4.1.

@lpd lpd mannequin closed this as completed Jul 25, 2005
@lpd lpd mannequin assigned nnorwitz Jul 25, 2005
@lpd lpd mannequin added the build The build process and cross-build label Jul 25, 2005
@lpd lpd mannequin closed this as completed Jul 25, 2005
@lpd lpd mannequin assigned nnorwitz Jul 25, 2005
@lpd lpd mannequin added the build The build process and cross-build label Jul 25, 2005
@loewis
Copy link
Mannequin

loewis mannequin commented Aug 6, 2005

Logged In: YES
user_id=21627

So can you tell us whether there are missing prerequisite
headers? One would need to have access to your operating
system to resolve this issue.

@jp3g
Copy link
Mannequin

jp3g mannequin commented Aug 9, 2005

Logged In: YES
user_id=1203137

Hey folks,

Also seeing this issue on 3.7. Same setup described above.
Loewis, not sure about the first part of your comment. If
your asking if those header files exist and are available,
yes they are (atleast on my system).

@loewis
Copy link
Mannequin

loewis mannequin commented Aug 9, 2005

Logged In: YES
user_id=21627

Can somebody attach a config.log, or reproduce the fragment
that deals with the curses.h presence?

Does your system require any headers to be included for
curses.h to be usable? I.e. if you do

#include <curses.h>
int main(){}

will that program compile, or do you need additional
('prerequisite') headers?

@hyeshik
Copy link
Contributor

hyeshik commented Aug 28, 2005

Logged In: YES
user_id=55188

For curses.h problem, it doesn't harm the build much in
fact. It's already reported to FreeBSD bugdb
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=84219 and I think
it's identical problem on OpenBSD.

@lpd
Copy link
Mannequin Author

lpd mannequin commented Sep 25, 2005

Logged In: YES
user_id=8861

OK, I've found out what goes wrong. (Debugging a
20,000+-line 'configure' script that omits all useful
information from its output and throws away all its
intermediate files *even if it detects errors* is not fun.)

With the set of configuration options that the script
decides is appropriate (too long to include here),
compilation of a dummy .c file that #includes <curses.h>
fails thusly:

In file included from /usr/include/curses.h:14,
from t.h:54,
from t.c:1:
/usr/include/ncurses.h:251: error: conflicting types for
wchar_t' /usr/include/stdlib.h:51: error: previous declaration of wchar_t'

This apparently happens because of line 1483 of the
configure script, which reads:

OpenBSD/2.* | OpenBSD/3.[0123456])

I can't fathom why OpenBSD 3.7 and later are excluded here,
especially since (1) there are other places in the script
that include all OpenBSD/3.* versions, and (2) the situation
described by the comment just above this line is still true
in OpenBSD 3.7. In any case, changing this line to read

OpenBSD/2.* | OpenBSD/3.*)

causes configure (and a subsequent make) to complete with no
errors. So apparently other things are broken in the OpenBSD
headerfiles if _XOPEN_SOURCE is defined, not just select(2).

I hope someone authorized to do so will make this fix for
Python 2.4.<N+1>. TIA.

@loewis
Copy link
Mannequin

loewis mannequin commented Sep 25, 2005

Logged In: YES
user_id=21627

The issue reported here results from a bug in OpenBSD:
ncurses.h and stdlib.h have conflicting definitions of
wchar_t. This means the system is simply broken, and should
be fixed (or abandoned) eventually.

Python has a work-around for the bug, for those versions in
which the bug has been confirmed. So far, the bug had not
been confirmed for 3.7. Now it is, so we should add 3.7 to
the list of systems that still show the bug. Changing it to
3.* would be incorrect - we cannot know whether the bug will
be present in 3.8, as that system has not been released yet.

@nnorwitz
Copy link
Mannequin

nnorwitz mannequin commented Jan 9, 2006

Logged In: YES
user_id=33168

Committed revision 41984.
Committed revision 41985. (2.4)

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build The build process and cross-build
Projects
None yet
Development

No branches or pull requests

1 participant