The gdb hooks for debugging CPython (within Tools/gdb) have
been enhanced to show information on more C frames relevant to CPython within
the "py-bt" and "py-bt-full" commands:
* C frames that are waiting on the GIL
* C frames that are garbage-collecting
* C frames that are due to the invocation of a PyCFunction
python executable
The __os_install_macro defines some post-processing activities during an rpm
build; one of the scripts it calls is brp-python-bytecompile, which can take
an argument: the python executable with which to byte-compile .py files in the
package payload.
In some older versions of rpm (e.g. in RHEL 6), this invocation doesn't pass
in an argument, and brp-python-bytecompile defaults to using /usr/bin/python,
which can lead to the .py files being byte-compiled for the wrong version of
python. This has been fixed in later versions of rpm by passing in
%{__python} as an argument to brp-python-bytecompile.
Workaround this by detecting if __os_install_post has a 0-argument invocation
of brp-python-bytecompile, and if so generating an equivalent macro that has
the argument, and explicitly provide the new definition within the specfile.
python executable
The __os_install_macro defines some post-processing activities during an rpm
build; one of the scripts it calls is brp-python-bytecompile, which can take
an argument: the python executable with which to byte-compile .py files in the
package payload.
In some older versions of rpm (e.g. in RHEL 6), this invocation doesn't pass
in an argument, and brp-python-bytecompile defaults to using /usr/bin/python,
which can lead to the .py files being byte-compiled for the wrong version of
python. This has been fixed in later versions of rpm by passing in
%{__python} as an argument to brp-python-bytecompile.
Workaround this by detecting if __os_install_post has a 0-argument invocation
of brp-python-bytecompile, and if so generating an equivalent macro that has
the argument, and explicitly provide the new definition within the specfile.
no longer lose data when an underlying read system call is interrupted.
IOError is no longer raised due to a read system call returning EINTR
from within these methods.
no longer lose data when an underlying read system call is interrupted.
IOError is no longer raised due to a read system call returning EINTR
from within these methods.
parameter from os.remove / os.unlink.
Patch written by Georg Brandl. (I'm really looking forward to George
getting commit privileges so I don't have to keep doing checkins on his
behalf.)
- Try to avoid building Python or extension modules with problematic
llvm-gcc compiler.
- Since Xcode 4 removes ppc support, extension module builds now
check for ppc compiler support and automatically remove ppc and
ppc64 archs when not available.
- Since Xcode 4 no longer install SDKs in default locations,
extension module builds now revert to using installed headers
and libs if the SDK used to build the interpreter is not
available.
- Update ./configure to use better defaults for universal builds;
in particular, --enable-universalsdk=yes uses the Xcode default
SDK and --with-universal-archs now defaults to "intel" if ppc
not available.
