This inappropriately disabled some capabilities which exist.
Now test for readline in -lreadline, if not found there, try it
in -ltermcap only if not in -lreadline. If both libraries are
required, there will need to be more work, but I'm not sure
under what conditions both libraries would be required.
POSIX is enabled. This prevents the toolbox glue, all of Carbon,
and various other non-POSIX features from compiling. The POSIX
symbols are still used by default, so turning off the #define
doesn't hurt.
Additionally, linker flags have changed for Darwin 8, and are
different for Darwin 8/gcc4 (default) and Darwin 8/gcc3.3.
Approved by Anthony
MacOSX: if we cannot use -undefined dynamic_lookup (such as on 10.2 or earlier)
we link extension directly against the dynamic library in the framework in
stead of against the framework. This will fix building extensions for 2.3
after 2.4 has been installed too.
to make using "-undefined dynamic_lookup" for linking extensions more
automatic on 10.3 and later. So if we're on that platform and
MACOSX_DEPLOYMENT_TARGET is not set we now set it to the current OSX
version during configure. Additionally, distutils will pick up the
configure-time value by default.
Will backport.
because GNU/k*BSD uses gnu pth to provide pthreads, but will also happen on any
system that does the same.
python fails to build because it doesn't detect gnu pth in pthread
emulation. See C comments in patch for details.
patch taken from http://bugs.debian.org/264315
[ 960406 ] unblock signals in threads
although the changes do not correspond exactly to any patch attached to
that report.
Non-main threads no longer have all signals masked.
A different interface to readline is used.
The handling of signals inside calls to PyOS_Readline is now rather
different.
These changes are all a bit scary! Review and cross-platform testing
much appreciated.
of hard linking against the framework).
If $MACOSX_DEPLOYMENT_TARGET is set, and >= 10.3, during configure we
setup extensions to link with dynamic lookup. We also record the
value in the Makefile.
Distutils checks whether a value for MACOSX_DEPLOYMENT_TARGET was
recorded in the Makefile, and if it was insists that the current
value matches.
This is only a partial fix because it only applies to 2.4, and the
"two python problem" exists with Python 2.3 shipped with MacOSX 10.3,
which we have no influence over.
