New submission from Nathaniel Smith:
It turns out that CPython built with --with-fpectl has a different ABI than
CPython built without --with-fpectl (which is the default). Specifically, if
you have an extension module built against a --with-fpectl CPython, and it uses
the PyFPE_{START,END}_PROTECT macros (as e.g. Cython modules do), then it ends
up referring to some symbols that aren't provided by no-fpectl CPython builds.
These macros are part of the stable ABI, so it's possible (though unlikely?)
that there are existing modules using the stable ABI that refer to these
symbols.
Mailing list discussion:
December:
https://mail.python.org/pipermail/python-dev/2016-December/147065.html
January:
https://mail.python.org/pipermail/python-dev/2017-January/147092.html
Guido's "let's get rid of it":
https://mail.python.org/pipermail/python-dev/2017-January/147094.html
There are 3 parts to the fpectl machinery:
- macros PyFPE_{START,END}_PROTECT in Include/pyfpe.h, which are part of the
public C API. Depending on --with-fpectl, these are either no-ops, or else
refer to:
- global symbols PyFPE_{jbuf,counter,dummy}, defined in Python/pyfpe.c iff
--with-fpectl is enabled.
- the stdlib module 'fpectl' (Modules/fpectlmodule.c) which provides some
Python APIs that make use of the information that the macros put into the
global symbols. (If the user doesn't use fpectl, then the macros do nothing
except update the global variables.)
>From the python-dev discussion, I think the resolution is:
- for all supported CPython releases, we should modify Python/pyfpe.c so that
the PyFPE_jbuf and PyFPE_counter are defined unconditionally. (I.e., remove the
#ifdef WANT_SIGFPE_HANDLER that currently protects their definitions). After
this change, all CPython builds will be able to import all CPython extension
modules (though the actual fpectl functionality may or may not be available).
- in the next 3.5 and maybe 3.4 releases, we should add a deprecation warning
to the fpectl module.
- in the next 2.7 release, we should add a Py3k warning to the fpectl module.
- in trunk / 3.7, we should remove --with-fpectl and the fpectl stdlib module
entirely. For stable API compatibility we might want to leave the PyFPE_*
macros (defined as no-ops) and/or the PyFPE_{jbuf,counter,dummy} symbols, but
nothing will actually use them.
----------
components: Extension Modules
messages: 284511
nosy: njs
priority: normal
severity: normal
status: open
title: Fix fpectl-induced ABI breakage
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29137>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
