[Python-bugs-list] [Bug #116172] 2.0b2 curses module fails to build on SGI

[noreply@sourceforge.net]

Bug #116172, was updated on 2000-Oct-05 12:40
Here is a current snapshot of the bug.

Project: Python
Category: Build
Status: Open
Resolution: None
Bug Group: Platform-specific
Priority: 3
Summary: 2.0b2 curses module fails to build on SGI

Details: I didn't see this in the database.

Trying to build 2.0b2 here on SGI IRIX 6.5.  I have this
line in Setup:

     _curses _cursesmodule.c -lcurses -ltermcap

This used to work on 1.5.2 on IRIX 6.5, but it doesn't with 2.0b2.

Here is a digested version of the errors:

cc -n32  -O -KPIC -I./../Include -I.. -DHAVE_CONFIG_H -c ./_cursesmodule.c
...
  The identifier "attr_t" is undefined.
  The identifier "ACS_S3" is undefined.
  The identifier "ACS_LEQUAL" is undefined.
  The identifier "ACS_GEQUAL" is undefined.
  The identifier "ACS_PI" is undefined.
  The identifier "ACS_NEQUAL" is undefined.
  The identifier "ACS_STERLING" is undefined.
  A value of type "int" cannot be assigned to an entity of type "char *".
        capname = tigetstr( capname );
                ^
  The identifier "A_HORIZONTAL" is undefined.
  The identifier "A_LEFT" is undefined.
  The identifier "A_LOW" is undefined.
  The identifier "A_RIGHT" is undefined.
  The identifier "A_TOP" is undefined.
  The identifier "A_VERTICAL" is undefined.


Follow-Ups:

Date: 2000-Oct-06 07:50
By: gvanrossum

Comment:
I don't know, but I think this may be caused by IRIX having an old, incompatible version of curses. So it probably won't work. Too bad. You may be able to get a different curses implementation (there must be a free one that comes with Linux???).
-------------------------------------------------------

Date: 2000-Oct-06 08:42
By: jhylton

Comment:
Eric, can you look at this today?
-------------------------------------------------------

Date: 2000-Oct-06 11:26
By: VizNut

Comment:
A quick grep reveals Sun Solaris 7 doesn't have them either.

If the intent is to break with standard curses, to avoid confusion it might be best to rename the module from curses to "linux_curses" or "ncurses" (if that's the appropriate curses variety).

Thanks,

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

Date: 2000-Oct-12 10:42
By: gvanrossum

Comment:
This appears to be simply a matter of the platform's curses library being *reeeeeeeally* old. So I'm lowering the priority.

The ncurses API is actually quite old, and vendors have no excuse for not providing it. That's why it's not a good idea to call the module linuxcurses or ncurses.

However, it's quite possible that your vendor provides both the old curses API and the ncurses API, under those names. In that case it shouldn't be hard to change the source code to include "ncurses.h" and the Makefile to link with -lncurses. If you get this working, I'd be glad to accept a patch via the SourceForge Patch manager! This can't be done in 2.0 though (we're in a code freeze stage right now where only critical bugfixes may be checked in).
-------------------------------------------------------

Date: 2000-Oct-20 10:45
By: akuchling

Comment:
Clarification: ncurses implements the SYSV curses API,
which adds a lot of features on top of the old BSD curses API.  For example, Solaris doesn't use ncurses, but it does 
support the SYSV API, and the module should work there.

There's a STRICT_SYSV_CURSES macro that can be defined 
in _cursesmodule.c that removes certain features that
aren't on every SYSV curses platform.  That macro should be 
defined on SGI, from the following code:

#if defined(__sgi__) || defined(__sun__)
#define STRICT_SYSV_CURSES       /* Don't use ncurses extensions */
typedef chtype attr_t;           /* No attr_t type is available */
#endif                                                                          

Does your compiler not define __sgi__?  Perhaps some different macro should be used for this feature test.

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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=116172&group_id=5470