Bugs item #1244610, was opened at 2005-07-25 18:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 build fails on OpenBSD 3.7 Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2005-09-25 06:23 Message: 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. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2005-09-25 04:10 Message: 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. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2005-08-28 10:10 Message: 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. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2005-08-09 20:40 Message: 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? ---------------------------------------------------------------------- Comment By: johnnie pittman (jp3g) Date: 2005-08-09 08:34 Message: 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). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:43 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1244610&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
