This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: curses module build failure (ncurses 5.7)
Type: Stage: resolved
Components: Build Versions: Python 3.1, Python 3.2, Python 2.7, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, mark.dickinson
Priority: normal Keywords:

Created on 2009-09-06 12:53 by mark.dickinson, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg92312 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-09-06 12:53
There seems to be a problem building the curses module on systems with 
ncurses 5.7.  The following output was produced on OS X 10.6, on a trunk 
build;  I'm not sure whether this problem is Mac-specific (or 64-bit 
specific).

building '_curses' extension
gcc -fno-strict-aliasing -g -Wall -Wstrict-prototypes -
I/Users/dickinsm/python/svn/trunk/Mac/Include -I. -I./Include -IInclude 
-I/Users/dickinsm/python/svn/trunk -c 
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c -o 
build/temp.macosx-10.4-i386-2.7-
pydebug/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.o
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function 
‘PyCursesWindow_EchoChar’:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:805: error: 
dereferencing pointer to incomplete type
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:812: warning: 
control reaches end of non-void function
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function 
‘PyCursesWindow_NoOutRefresh’:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1230: error: 
dereferencing pointer to incomplete type
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1261: warning: 
control reaches end of non-void function
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function 
‘PyCursesWindow_Refresh’:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1372: error: 
dereferencing pointer to incomplete type
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1402: warning: 
control reaches end of non-void function
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function 
‘PyCursesWindow_SubWin’:
/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1438: error: 
dereferencing pointer to incomplete type

Here's a relevant excerpt from _cursesmodule.c (lines 804--811)

#ifdef WINDOW_HAS_FLAGS
  if (self->win->_flags & _ISPAD)
    return PyCursesCheckERR(pechochar(self->win, ch | attr),
                            "echochar");
  else
#endif
    return PyCursesCheckERR(wechochar(self->win, ch | attr),
                            "echochar");

Here self->win has type WINDOW;  the problem is that as of ncurses 5.7, the internals of the WINDOW type (and much else besides) are deliberately hidden (by default) from users of the library;  there's a 
preprocessor constant NCURSES_OPAQUE that controls this.

So an obvious workaround is to set NCURSES_OPAQUE=0 somewhere in the 
Python build process;  however, that may be the wrong thing to do if the ncurses developers are planning to mess with the ncurses internals in 
the near future (which would explain the NCURSES_OPAQUE business).  I 
don't know whether there's some alternative 'official' way to 
distinguish between ncurses windows and pads.
msg92329 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-09-06 20:35
I asked on the ncurses-bugs mailing list about this problem, and got an 
immediate and helpful reply from the ncurses maintainer (Thomas Dickey).

It turns out that this *is* a Mac-specific problem: in Snow Leopard the 
Apple-supplied ncurses.h defines NCURSES_OPAQUE to 1 (if it isn't already 
defined) by default, while a standard ncurses install defines 
NCURSES_OPAQUE to be 0 by default.  Furthermore, Thomas Dickey has said 
that he'll add an is_pad function for later use, so if the WINDOW flags do 
disappear or move in a future version of ncurses then there should be an 
easy workaround available at that time.

So just #defining NCURSES_OPAQUE to 0 for OS X >= 10.6 seems a reasonable 
way to fix this for now.
msg92331 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-09-06 20:47
On Sun, Sep 6, 2009 at 13:35, Mark Dickinson<report@bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm@gmail.com> added the comment:
>
> I asked on the ncurses-bugs mailing list about this problem, and got an
> immediate and helpful reply from the ncurses maintainer (Thomas Dickey).
>
> It turns out that this *is* a Mac-specific problem: in Snow Leopard the
> Apple-supplied ncurses.h defines NCURSES_OPAQUE to 1 (if it isn't already
> defined) by default, while a standard ncurses install defines
> NCURSES_OPAQUE to be 0 by default.  Furthermore, Thomas Dickey has said
> that he'll add an is_pad function for later use, so if the WINDOW flags do
> disappear or move in a future version of ncurses then there should be an
> easy workaround available at that time.
>
> So just #defining NCURSES_OPAQUE to 0 for OS X >= 10.6 seems a reasonable
> way to fix this for now.

Seems reasonable to me as well.
msg92336 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-09-06 21:28
Fixed in r74693, r74694, r74696, r74697.
History
Date User Action Args
2022-04-11 14:56:52adminsetgithub: 51097
2009-09-06 21:28:34mark.dickinsonsetstatus: open -> closed
versions: + Python 2.6, Python 3.1, Python 3.2
messages: + msg92336

resolution: fixed
stage: resolved
2009-09-06 20:47:02brett.cannonsetmessages: + msg92331
2009-09-06 20:35:15mark.dickinsonsetmessages: + msg92329
2009-09-06 20:20:40brett.cannonsetnosy: + brett.cannon
2009-09-06 12:53:30mark.dickinsoncreate