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

[noreply@sourceforge.net]

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: 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