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.
(Contributed by Bob Ippolito.)
This patch trims down the Python core on Darwin by making it
independent of CoreFoundation and CoreServices. It does this by:
Changed linker flags in configure/configure.in
Removed the unused PyMac_GetAppletScriptFile
Moved the implementation of PyMac_StrError to the MacOS module
Moved the implementation of PyMac_GetFullPathname to the
Carbon.File module
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
discussed recently in python-dev:
In _locale module:
- bind_textdomain_codeset() binding
In gettext module:
- bind_textdomain_codeset() function
- lgettext(), lngettext(), ldgettext(), ldngettext(),
which return translated strings encoded in
preferred system encoding, if
bind_textdomain_codeset() was not used.
- Added equivalent functionality in translate()
function and catalog classes.
Every change was also documented.
[ 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.
two framework builds (in /Library and /System/Library) to coexist
with distutils linking against the right one.
Should be backported to 2.3, but getting Apple-supplied Python to pick
up these fixes is going to be non-trivial.