Co-authored-by: Lawrence D’Anna <lawrence_danna@apple.com>
* Add support for macOS 11 and Apple Silicon (aka arm64)
As a side effect of this work use the system copy of libffi on macOS, and remove the vendored copy
* Support building on recent versions of macOS while deploying to older versions
This allows building installers on macOS 11 while still supporting macOS 10.9.
* bpo-22490: Remove "__PYVENV_LAUNCHER__" from the shell environment on macOS
This changeset removes the environment varialbe "__PYVENV_LAUNCHER__"
during interpreter launch as it is only needed to communicate between
the stub executable in framework installs and the actual interpreter.
Leaving the environment variable present may lead to misbehaviour when
launching other scripts.
* Actually commit the changes for issue 22490...
* Correct typo
Co-Authored-By: Nicola Soranzo <nicola.soranzo@gmail.com>
* Run make patchcheck
Co-authored-by: Jason R. Coombs <jaraco@jaraco.com>
Co-authored-by: Nicola Soranzo <nicola.soranzo@gmail.com>
Plistlib currently throws an exception when asked to decode a valid
.plist file that was generated by Apple's NSKeyedArchiver. Specifically,
this is caused by a byte 0x80 (signifying a UID) not being understood.
This fixes the problem by enabling the binary plist reader and writer
to read and write plistlib.UID objects.
Values in the range of an unsigned long long, but outside of the range
of a signed long long were serialized as a negative value.
Due to a bug in PyObjC my test scripts indicated that the previous behavior
matched Apple's plist code, instead the handle large unsigned values correctly.
The change to plistlib.py is from a patch by Serhiy.
requires them. Disable executable bits and shebang lines in test and
benchmark files in order to prevent using a random system python, and in
source files of modules which don't provide command line interface. Fixed
shebang lines in the unittestgui and checkpip scripts.
requires them. Disable executable bits and shebang lines in test and
benchmark files in order to prevent using a random system python, and in
source files of modules which don't provide command line interface. Fixed
shebang line to use python3 executable in the unittestgui script.
* Negative integer support in binary plists was broken
* Better exception for invalid data
* Fix the versionadded/versionchanged markup in the documentation
* Add the interface cleanup to what's new for 3.4
This patch adds support for binary plists on OSX to plistlib (based
on a patch by 'dpounces').
The patch also cleans up the API for the plistlib module.
installer package from the OS X Makefile for Python 3. It has
never worked on Python 3 and is not needed there as pre-10.3.9
installs are no longer supported.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r81649 | ronald.oussoren | 2010-06-02 05:47:14 +0200 (Wed, 02 Jun 2010) | 5 lines
Fix for issue8868: without this patch 'MacOS.WMAvailable()' will return
False on MacOSX 10.5 or earlier and scripts won't be able to access GUI
functionality.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r79902 | ronald.oussoren | 2010-04-08 03:13:31 -0500 (Thu, 08 Apr 2010) | 9 lines
This check-in fixes two problems:
1) A non-critical off-by-one error in pythonw
2) A problem in the configure script that caused
builds with '--enable-framework --enable-universalsdk=/'
to fail on OSX 10.6.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77031 | ronald.oussoren | 2009-12-24 14:30:58 +0100 (Thu, 24 Dec 2009) | 15 lines
Issue #6834: replace the implementation for the 'python' and 'pythonw' executables on OSX.
The previous implementation used execv(2) to run the real interpreter, which means that
you cannot use the arch(1) tool to select the architecture you want to use for a
universal build because that only affects the python/pythonw wrapper and not the actual
interpreter.
The new version uses posix_spawnv with a number of OSX-specific options that ensure that
the real interpreter is started using the same CPU architecture as the wrapper, and that
means that 'arch -ppc python' now actually works.
I've also changed the way that the wrapper looks for the framework: it is now linked to
the framework rather than hardcoding the framework path. This should make it easier to
provide pythonw support in tools like virtualenv.
........
This the build machinery on OSX to re-enable building (and installing)
PythonLauncher.app and IDLE.app.
This needs ports of fixes to Lib/distutils/util.py and Include/pymacconfig.h
to be fully functiontional, to be fully functional.
I also have a patch for Makefile.pre.in that I'll post on bugs.python.org
for review.
Removal of the Mac modules broke many of the Mac scripts (including
BuildApplet.py) so the building of the Python launcher and IDLE.app was
broken. I manually copied built versions of those apps into Mac. Everything else
which used Mac modules had to die.
