[Python-Dev] HP-UX clean-up (original) (raw)

Cameron Laird claird at lairds.com
Tue Jan 6 15:43:18 EST 2004

From tim.one at comcast.net Sat Jan 03 19:31:55 2004 > ... > Has anyone been in contact with the HP-UX Porting Center > folks recently? I wonder if I should enlist their help ...

If and only if they know something about HP-UX <0.5 wink>. Nobody here really seems to. Have you tried their port? 2.3.1 appears to be the most recent:

http://hpux.cs.utah.edu/hppd/hpux/Languages/python-2.3.1/

By memory, in the past we've gotten complaints from HP-UX users about previous Porting Center Pythons in two areas:

1. Apparently some (all?) of their Python ports were built with threading disabled entirely.

2. Flaky floating-point behavior.

An example of the latter complaint is here (not a particularly good example, just the first I bumped into via Googling):

http://www.ifost.org.au/Software/

The python for HP-UX 11 that is found at the HP public domain software porting centre has buggy floating point problems. I recompiled it with gcc 3 and while there are some round-off issues, at least it's not totally deranged... [a link to python-211-hpux11-gcc.gz]

I'm far enough along to begin reporting to python-dev and soliciting the group as what Guido called a "crutch".

Issues: A. Threading: first, congratulations to Guido et al., for bringing it along this far. I think you've done the best possible.

Lots of HP-UX people seem to be building --without-threads.
I can imagine that the Porting Center will continue to do 
so.  We can help them do better, or at least more; I don't
know yet when that'll be the most important chore.

I want to make changes in threading's configuration.  I
want first to collect more information, so I can explain
myself with precision.

B. Version: I'd like good support to go back at least to 10.20. If someone thinks, "Nah, 11.01 and higher is good enough," I'd like to know now. C. curses: I find this hairy.

Is there a clean way to build without curses?  The only way
I know to advance without it is to hack up setup.py, speci-
fically to comment out the blocks that involve curses.

Here are the symptoms:  curses involves a
  cc -Ae -DNDEBUG -O +z -I. \
-I$SRC_ROOT/./Include \
-I/tmp/test4/include -I/usr/local/include \
-I$SRC_ROOT/Include \
-I$SRC_ROOT -c \
$SRC_ROOT/Modules/_cursesmodule.c
This tosses
  cc: "$SRC_ROOT/Modules/_cursesmodule.c", line 306: error 1000: \
         Unexpected symbol: "}".
  cc: error 2017: Cannot recover from earlier errors, terminating.
The source in _cursesmodule.c in that vicinity is
  ...
  #define Window_NoArg2TupleReturnFunction(X, TYPE, ERGSTR) \
  static PyObject * PyCursesWindow_ ## X (PyCursesWindowObject *self) \
  { \
TYPE arg1, arg2; \
X(self->win,arg1,arg2); return Py_BuildValue(ERGSTR, arg1, arg2); }
  ...
  Window_NoArg2TupleReturnFunction(getyx, int, "ii")
  Window_NoArg2TupleReturnFunction(getbegyx, int, "ii")
  Window_NoArg2TupleReturnFunction(getmaxyx, int, "ii")
  Window_NoArg2TupleReturnFunction(getparyx, int, "ii")
  ...

/usr/include/curses.h defines
  #define getyx(__win,__y,__x)    { WINDOW *__wi; \
                   __wi = __win;  \
                   ((__y) = __getcury(__wi), \
                   (__x) = __getcurx(__wi)) }
so the pre-processed form of the source is
   /* Re-formatted for ease in reading white space. */
   static PyObject * PyCursesWindow_getyx (PyCursesWindowObject *self)
   {
       int arg1, arg2;
       { WINDOW *__wi; __wi = self->win;
         ((arg1) = __getcury(__wi), (arg2) = __getcurx(__wi))
       };
       return Py_BuildValue("ii", arg1, arg2);
    }
which is, indeed, a fatal error.

Does anyone see the right fix?  I sure haven't, yet.

D. Other: there are others. I don't yet have good diagnoses.

More information about the Python-Dev mailing list