The attached patch makes Python build on QNX.  If I submit a similar patch for the 2.5 branch, would it be applied?

Here's an updated patch.  It's changed relative to the first one in that it makes the workaround for the incompatibility between [n]curses.h and stdlib.h be handled similar to how it's handled for other platforms, it prevents _XOPEN_SOURCE from being defined to allow the socket module to build, and it merges the QNX case for setting LDSHARED.

I tried to include the changes to configure and pyconfig.h.in, but that made it too big.  If they need to be submitted, please let me how to do so.
File Added: patch

Martin, will you take a look?

...and here's another revision.  This patch makes sys/termio.h be included before termios.h in order to ensure that TCGETA, TCSETA, TCSETAW, and TCSETAF can be used so that the termios module can be built, sets the stack size to 2 megabytes so that test_compile.py doesn't overflow the stack, and adds some comments to configure.in.

With it, the test suite can be run to completion, though there are still a number of errors and failures.

Sorry for the churn.
File Added: patch

Here's a new patch.  It differs from the previous version in that it excludes nis from the list of modules to be built (since QNX does not provide the necessary header files) and allows the ctypes module to be built.  Since it modifies libffi's configure.ac, autoconf must be run to regenerate its configure also.
File Added: patch

A 2.5 patch would not be accepted; there won't be any new features 
for 2.5 , and new port would be a new feature.

Procedurally, are you willing to support a QNX port for the coming years
(say, 5 years)? Otherwise, there is little point in accepting such a
port if there is no maintenance to it.

In general, I would prefer if the things this patch corrects were
detected through autoconf, rather than being hard-coded by system name.

For example, if using TCGETA and TCSETA requires sys/termio.h to be
included, there should be an autoconf test that checks whether TCGETA
can be used without sys/termio.h being included, and, if not, defines a
macro that says so.

However, I don't understand this entire point: What do you mean by
"using TCGETA requires that struct termio be defined"? How is TCGETA
defined to produce such a dependency? TCGETA is a constant, right?

py_curses.h: Can you explain what stdlib.h and ncurses.h define to guard
definition of wchar_t? Why do you have two cases: _XOPEN_SOURCE_EXTENDED
and not? Surely only one of them applies to Python. Can you come up with
an autoconf test that checks whether stdlib.h defines wchar_t and has a
guard and that ncurses also defines wchar_t and fails to compile if it
is guarded differently?

stack size: it would be good if it was sized by default such that the
default recursion limit won't cause crashes (but proper stack
overflows). If 2MiB are sufficient for the default recursion limit, it's
fine - otherwise, either reserver more stack, or reduce the default
recursion limit.

malloc_closure should use _SC_PAGESIZE when it is defined, and fall back
to getpagesize only otherwise.

look this
http://www.mail-archive.com/python-bugs-list%40python.org/msg07749.html
it's for python-2.3.5 under qnx4.25.

about pyport.h under qnx4.25:
I include "unix.h" instead of definition of function 
openpty()+forkpty() in pyport.h, openpty()+forkpty() naturaly defined 
in "unix.h" but configure doesn't knows.

However, I don't understand this entire point: What do you mean by
"using TCGETA requires that struct termio be defined"? How is TCGETA
defined to produce such a dependency? TCGETA is a constant, right?
-------------------------------------------------------------------
terminal I/O control has three different implementations under SVR4, 
BSD, and POSIX.1. 

SVR4 uses the termio structure, and various ioctl calls (such as 
TCGETA, TCSETA, TCSETAW, and TCSETAF) on a terminal device to obtain 
and set parameters with the termio structure.

Under POSIX, the termios struct is used, along with various functions 
defined by POSIX.1, such as tcsetattr and tcgetattr.

Under QNX
<termios.h> - is POSIX implimentation with functions tcsetattr and 
tcgetattr defined, but in <ioctl.h> that included in <termio.h> define 
MACROS TCGETA, TCSETA, TCSETAW, and TCSETAF.
That's why we need <termio.h> or simlink <sys/termio.h>.
Why do you want TCGETA, TCSETA, TCSETAW, and TCSETAF in Python if 
there is POSIX tcsetattr and tcgetattr functions?

addition
TCGETA is a constant. That's right!
under QNX4 TCGETA defined as MACRO in <sys/ioctl.h>. That's right!
in Modules/termios.c there's
#include <sys/ioctl.h>
That's right too!
What's problem after all?
Problem is that MACRO definition of TCGETA need sizeof(struct termio),
that's (struct termio) defined in <sys/termio.h>.
But <sys/termio.h> not included in <sys/ioctl.h> instead of it
<sys/ioctl.h> included in <sys/termio.h> and we need, if we want to 
have TCGETA, start with <sys/termio.h> that's included both 
<sys/ioctl.h> and <termios.h> too and do it right way!
It's clearly now?

I still don't get the point of including sys/termio.h. Python does *not*
use the TCGETA macro itself *at all*. Python applications may, but they
can't use the included sys/termio.h, since they are written in Python,
not in C. To put the question the other way: If you remove the first
chunk of the patch 4 (the change to pyport.h), will Python fail to
compile on QNX? If so, what is the error message.

Please also address my other remarks, in particular this one:

Are you willing to support a QNX port for the coming years
(say, 5 years)?

I'm willing to maintain the QNX 6 port, but I can't promise that I'll be
able to do so for 5 years.  I don't know if that's sufficient or not.

willing you implement thread support for qnx6, or may be qnx4?

I'm not interested in QNX 4, as that's not what I use.  I'd be willing
to supporting threads on QNX 6.

I think it's fine to accept this (once the remaining issues are
resolved) -- it's a remarkably small patch.

Regarding TCGETA, perhaps the issue is that it isn't defined unless
<sys/termio.h> is included?  While Python doesn't USE it, it exports it
fro the termios module, if it exists.  Though the suggestion that this
should be resolved by configure is still a good one.  Matt, can you
provide an updated patch or clarifications?

If they're defined, TCGETA, TCSETA, TCSETAW, and TCSETAF are used on
lines 702, 714, 717, and 720 of Modules/termios.c as of r60219.  They
are defined by sys/ioctl.h as

 #define TCGETA          _IOR('T', 1, struct termio)
 #define TCSETA          _IOW('T', 2, struct termio)
 #define TCSETAW         _IOW('T', 3, struct termio)
 #define TCSETAF         _IOW('T', 4, struct termio)

These macro definitions expand to

 ( 0x40000000   | ((  sizeof(  struct termio )  & 0x3fff ) << 16) | (( 
  ( 'T' ) ) << 8) | (  (  1 ) ))   
 ( 0x80000000   | ((  sizeof(  struct termio )  & 0x3fff ) << 16) | (( 
   ( 'T' ) ) << 8) | (  (  2 ) ))   
 ( 0x80000000   | ((  sizeof(  struct termio )  & 0x3fff ) << 16) | (( 
   ( 'T' ) ) << 8) | (  (  3 ) ))   
 ( 0x80000000   | ((  sizeof(  struct termio )  & 0x3fff ) << 16) | (( 
   ( 'T' ) ) << 8) | (  (  4 ) ))   

respectively, so struct termio must be declared if any of these macros
are used.  struct termio is declared in sys/termio.h.  Since
sys/termio.h isn't included, Modules/termios.c fails to compile with the
following error messages:

 /home/m_kraai/src/python/Modules/termios.c:702: sizeof applied to an
incomplete type
 /home/m_kraai/src/python/Modules/termios.c:714: sizeof applied to an
incomplete type
 /home/m_kraai/src/python/Modules/termios.c:717: sizeof applied to an
incomplete type
 /home/m_kraai/src/python/Modules/termios.c:720: sizeof applied to an
incomplete type

sys/termio.h checks that it's included before termios.h is first
included.  If it's not included first, it produces the following error
message:

 /usr/qnx630/target/qnx6/usr/include/sys/termio.h:109: #error
termio/termios incompatibility

What should configure test for?

Thanks for the explanation; that makes sense (I didn't expect that the
value of these constants depends on the size of some structure,
normally, they are "truly" constant, e.g. 0x5405 on Linux).

The autoconf test should check whether the header (sys/termio.h) is
present, and then a conditional include of termio.h should be made under
HAVE_SYS_TERMIO_H, with the a comment "for TCGETA" or some such. This
would fix the problem for any other system that has the same approach to
ioctl codes.

This patch contains two improvements over the previous version:

 * it uses configure to check whether sys/termio.h is available and uses
the result to determine whether to include it and
 * it makes malloc_closure.c use _SC_PAGESIZE instead of getpagesize if
it's available.

I believe there are two unresolved issues at this point, the wchar_t
definition and the stack size.

[n]curses.h defines wchar_t if _XOPEN_SOURCE_EXTENDED is defined and if
_WCHAR_T is not defined:

 #ifdef _XOPEN_SOURCE_EXTENDED
 #ifndef _WCHAR_T
 typedef unsigned long wchar_t;
 #endif /* _WCHAR_T */
 #ifndef _WINT_T
 typedef long int wint_t;
 #endif /* _WINT_T */

stdlib.h defines wchar_t if __WCHAR_T is defined:

 #if defined(__WCHAR_T)
 typedef __WCHAR_T       wchar_t;
 #undef __WCHAR_T
 #endif

I'm afraid I don't quite understand what configure should test for in
this case either.  Please help!

Regarding the stack size, how can I test whether 2MiB is sufficient for
the default recursion limit?

I don't understand the ncurses issue:
you already disable the definition of _XOPEN_SOURCE in the patch, hence
_XOPEN_SOURCE_EXTENDED does not get defined, hence ncurses should not
define wchar_t. So what's the actual problem that this fragment solves?
As for stdlib.h: *Is* __WCHAR_T defined on your system, normally?

Re stack size: maybe I misunderstood what the patch does. Is it the case
that, with the patch, the interpreter won't crash, but gives a
RuntimeError instead?

For _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED
look this
http://opengroup.org/onlinepubs/007908775/xcurses/implement.html

there is script
Misk/find_recursionlimit.py 
that can help to find real recursion limit
for QNX4 for one recursion used ~900 kb of stack thus 1Mb sufficient 
for default recursion limit = 1000.

Regarding the curses issue, I removed that portion of the patch and the
curses module still compiled.  It must have been an artifact from before
I disabled _XOPEN_SOURCE.  Thanks for catching that.

Regarding the stack size, without the "-N 2048K" option, "make test"
fails as follows:

 ...
 test_compare
 test_compile
 make: *** [test] segmentation violation (core dumped)

The default recursion limit returned by sys.getrecursionlimit() is 1000,
 and Misc/find_recursionlimit.py says that 1100 is fine.  With -N 2048K,
test_compile does not produce a segmentation fault and
Misc/find_recursionlimit.py says that 4700 is fine.

Thanks for the patch. Committed as r63562.