[Python-bugs-list] [ python-Bugs-232597 ] _curses build broken on Compaq Tru64 Unix
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 10 Apr 2001 12:10:10 -0700
Bugs item #232597, was updated on 2001-02-15 12:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232597&group_id=5470
Category: Build
Group: Platform-specific
Status: Open
Priority: 2
Submitted By: Mark Favas (mfavas)
Assigned to: Nobody/Anonymous (nobody)
>Summary: _curses build broken on Compaq Tru64 Unix
Initial Comment:
2.1a2 from CVS of Feb 16 produces the following compiler warnings on Tru64
Unix (uname -a: OSF1 gonzo.per.dem.csiro.au V4.0 1229 alpha, Compaq C compiler, version: Compaq C V6.3-129 (dtk), Compiler Driver V6.3-126 (dtk)):
cc -c -O -Olimit 1500 -I. -I./Include -DHAVE_CONFIG_H -o Python/ceval.o Python/ceval.c
cc: Info: Python/ceval.c, line 327: Trailing comma found in enumerator list. (trailcomma)
};
cc -O -Olimit 1500 -I. -I./Include -IInclude/ -I/usr/local/include -c Modules/_cursesmodule.c -o build/temp.osf1-V4.0-alpha-2.1/_cursesmodule.o
cc: Warning: Modules/_cursesmodule.c, line 632: In this statement, "derwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
win = derwin(self->win,nlines,ncols,begin_y,begin_x);
cc: Warning: Modules/_cursesmodule.c, line 1287: In this statement, "subpad(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
win = subpad(self->win, nlines, ncols, begin_y, begin_x);
cc: Warning: Modules/_cursesmodule.c, line 1517: In this statement, "termname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
NoArgReturnStringFunction(termname)
cc: Warning: Modules/_cursesmodule.c, line 1686: In this statement, "getwin(...)" of type "int", is being converted to "pointer to struct _win_st". (cvtdiftypes)
win = getwin(PyFile_AsFile(temp));
cc: Warning: Modules/_cursesmodule.c, line 1954: In this statement, "keyname(...)" of type "int", is being converted to "pointer to const char". (cvtdiftypes)
knp = keyname(ch);
cc: Warning: Modules/_cursesmodule.c, line 2245: In this statement, "tigetstr(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
capname = tigetstr( capname );
cc: Warning: Modules/_cursesmodule.c, line 2270: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
result = tparm(fmt);
cc: Warning: Modules/_cursesmodule.c, line 2273: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
result = tparm(fmt,i1);
cc: Warning: Modules/_cursesmodule.c, line 2276: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
result = tparm(fmt,i1,i2);
cc: Warning: Modules/_cursesmodule.c, line 2279: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
result = tparm(fmt,i1,i2,i3);
cc: Warning: Modules/_cursesmodule.c, line 2282: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
result = tparm(fmt,i1,i2,i3,i4);
cc: Warning: Modules/_cursesmodule.c, line 2285: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
result = tparm(fmt,i1,i2,i3,i4,i5);
cc: Warning: Modules/_cursesmodule.c, line 2288: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
result = tparm(fmt,i1,i2,i3,i4,i5,i6);
cc: Warning: Modules/_cursesmodule.c, line 2291: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7);
cc: Warning: Modules/_cursesmodule.c, line 2294: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8);
cc: Warning: Modules/_cursesmodule.c, line 2297: In this statement, "tparm(...)" of type "int", is being converted to "pointer to char". (cvtdiftypes)
result = tparm(fmt,i1,i2,i3,i4,i5,i6,i7,i8,i9);
cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg1" is fetched but not initialized. And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")
cc: Warning: Modules/_cursesmodule.c, line 310: The scalar variable "arg2" is fetched but not initialized. And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getparyx, int, "(ii)")
cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg1" is fetched but not initialized. And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")
cc: Warning: Modules/_cursesmodule.c, line 309: The scalar variable "arg2" is fetched but not initialized. And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getmaxyx, int, "(ii)")
cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg1" is fetched but not initialized. And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")
cc: Warning: Modules/_cursesmodule.c, line 308: The scalar variable "arg2" is fetched but not initialized. And there may be other such fetches of this variable that have not been reported in this compilation. (uninit1)
Window_NoArg2TupleReturnFunction(getbegyx, int, "(ii)")
----------------------------------------------------------------------
>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:10
Message:
Logged In: YES
user_id=6380
Changing the subject -- it's only about _curses now.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 12:09
Message:
Logged In: YES
user_id=6380
Having just discovered the Tru64 test machine at the SourceForge Compile Farm, I can confirm that the curses
module is not built correctly on that platform.
My suspicion is that there's a curses.h header for an ancient version of curses, so that the setup script is mistaken
in even trying to build the _curses module. I don't know how to prevent it from doing so though... Maybe a check
for a certain symbol in the curses.h header could be added to the setup.py script???
Andrew, I'm not reassigning this back to you, because you just unassigned it; but you really do seem to have the
knowledge to move this forward...
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-10 10:58
Message:
Logged In: YES
user_id=11375
Unassigning, since I have no way of debugging this problem.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2001-02-27 11:42
Message:
Logged In: YES
user_id=11375
The get*yx() calls are always defined as macros. This does
look like the correct curses.h header isn't being picked
up. Does Tru64's curses.h header require some magical
#define in order to work?
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-19 13:55
Message:
Looks like a different header may be needed to pick up the prototypes for many of these. Assigned to the curses module guy.
----------------------------------------------------------------------
Comment By: Thomas Wouters (twouters)
Date: 2001-02-16 04:14
Message:
The first warning is my mistake. I thought I fixed that in a more recent version of my continue-inside-try patch, but apparently I didn't. Fixed in revision 2.230 of Python/ceval.c
The warnings in Modules/_cursusmodule.c are most likely caused by undefined functions, though why you don't see an error for those beats me. (undefined functions default to int-returning functions, so that's probably why you see those warnings.)
The *other* warnings look damned legit, though, and the only reason they aren't is because getmaxyx and co. are (on the BSDI and Linux boxes I have acces to) defined as being macro calls, and in fact they *have* to be macro calls (or non-standard C calls) or they can't work. I'm not a curses expert, but I think an initialization is in place here (or just rewriting the silly macros so they make *sense* :-)
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232597&group_id=5470