[Python-bugs-list] [ python-Bugs-641455 ] curses module doesn't build on MacOSX

noreply@sourceforge.net noreply@sourceforge.net
Fri, 22 Nov 2002 04:24:25 -0800


Bugs item #641455, was opened at 2002-11-20 21:45
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=641455&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Martin v. Löwis (loewis)
Summary: curses module doesn't build on MacOSX

Initial Comment:
The curses module fails to build on MacOSX 10.2.
There is apparently a mismatch between two definitions of wchar_t:

In file included from /Users/jack/src/python/Include/py_curses.h:6,
                 from /Users/jack/src/python/Modules/_cursesmodule.c:113:
/usr/include/ncurses.h:282: conflicting types for `wchar_t'
/usr/include/stdlib.h:77: previous declaration of `wchar_t'

I'm assigning this to you since you seem to be the most frequent committer of cursesmodule.c, so I hope you know what may be going on. Feel free to assign it back if I'm guessing wrong here, and I'll do the hunting. 

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-11-22 13:24

Message:
Logged In: YES 
user_id=45365

This is since 10.2 (Jaguar). On 10.1 and before Apple
shipped a very old curses (that wasn't good enough for the
Python curses module), nowadays they're shipping ncurses.
There is a /usr/include/curses.h but it is a symlink to
/usr/include/ncurses.h (a fact which is apparently detected
by configure or the setup script), so ncurses is apparently
the only curses we have.

By "The patch refers to...", do you mean the comment? (As on
Darwin curses.h == ncurses.h I didn't know this wasn't the
normal setup. I'll change the comment).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-11-22 12:06

Message:
Logged In: YES 
user_id=21627

On what system does Apple ship this? Why does ncurses.h not
exist on the SF compile farm 10.1 system, which identifies
itself as

Darwin usf-cf-ppc-macosx-1 5.5 Darwin Kernel Version 5.5:
Thu May 30 14:51:26 PDT 2002;
root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC  Power Macintosh powerpc

It neither exists on Just's letterorror.xs4all.nl, so I doubt

Do you have a file /usr/include/curses.h on your system?

I don't think the patch is ok; I'd rather prefer Python to
use the system curses library
(/usr/include/libcurses.dylib). The patch also incorrectly
refers to curses.h, when the problem really is with ncurses.h.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-11-22 11:38

Message:
Logged In: YES 
user_id=45365

Well, ncurses is what Apple ships, so I don't think closing
this as third-party is a good idea. (I have submitted an
Apple bug report, id 3108061).

I've attached a patch that seems to fix the problem:
defining _WCHAR_T if _BSD_WCHAR_T_DEFINED_ is defined.

Assign back to me if you think this is okay.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-11-22 08:53

Message:
Logged In: YES 
user_id=21627

I'd say it is safe to test for _BSD_WCHAR_T_DEFINED_ in
ncurses.h.

Strictly speaking, you would need to recompile ncurses with
_XOPEN_SOURCE_EXTENDED, but that can be avoided since both
definitions define wchar_t to a four-byte integer type
(there are int-vs-long unsigned-vs-signed issues, but they
should not matter).

Yes, there are a number of functions in ncurses that use
wchar_t, but none of those functions are exposed in Python.

In any case, I'll close this bug as 3rdparty. I recommend
that you don't use ncurses, but use the system curses
library instead.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-11-21 21:54

Message:
Logged In: YES 
user_id=45365

Agreed: the two headers protect against mulitply-defining wchar_t, but do so with different symbols (stdlib uses _BSD_WCHAR_T_DEFINED_, ncurses _WCHAR_T).

I could simply define the one if the other is defined (inside an ifdef APPLE, even), but as I'm not familiar with curses at all I don't know whether that would break anything (i.e. are the wchar_t part of any API, for instance).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-11-21 00:04

Message:
Logged In: YES 
user_id=21627

Looks like a bug in the system headers to me, if both
stdlib.h and ncurses.h define a type wchar_t, but define
them in different ways.

In case ncurses.h is not a system header, but a package that
you have installed yourself, you should uninstall it - it
apparently has not been ported to OS X.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=641455&group_id=5470