| msg181454 - (view) |
Author: Dirkjan Ochtman (djc) *  |
Date: 2013-02-05 16:24 |
| I recently filed http://llvm.org/bugs/show_bug.cgi?id=15153, prompted by https://bugs.gentoo.org/show_bug.cgi?id=427338 (for 2.7, and https://bugs.gentoo.org/show_bug.cgi?id=427330 for 3.2), for which I found http://bugs.python.org/issue9852. Similar issues have subsequently been found in http://bugs.python.org/issue13370. The latter has been fixed in http://hg.python.org/cpython/rev/a425f2697273 (for 2.7 -- other branches were affected as well), but that fix is incorrectly scoped to just OS X. It looks like clang is actually right here, and gcc is wrong; see their bug at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 (clang has a bug for this at http://llvm.org/bugs/show_bug.cgi?id=15153). |
|
|
| msg181483 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *  |
Date: 2013-02-05 21:10 |
| The changes in CPython mentioned by you are in bundled copy of libffi for OS X (Modules/_ctypes/libffi_osx). You probably should report the problem to libffi upstream. Gentoo ebuilds of CPython use --with-system-ffi option, so any fixes in bundled copy of libffi (Modules/_ctypes/libffi) would not help in Gentoo. |
|
|
| msg181499 - (view) |
Author: Dirkjan Ochtman (djc) * |
Date: 2013-02-06 07:52 |
| Thanks, I've filed https://github.com/atgreen/libffi/issues/29. |
|
|
| msg181500 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2013-02-06 08:01 |
| I don't know how the main copy of libffi in the CPython tree is updated, and if it is a straight copy of the upstream release. Given the mercurial log I'd guess that Modules/_ctypes/libffi is libffi 3.0.11 with a small patch in Modules/_ctypes/libffi.diff. As Arfrever notes libffi_osx is used on OSX only, and that version is a fork of libffi shared with PyObjC (that is, I try to update the copy in the CPython tree whenever I have to update the copy for PyObjC). I agree that the issue with libffi should be fixed upstream first, otherwise it would get harder and harder to import new upstream versions. |
|
|
| msg181501 - (view) |
Author: Dirkjan Ochtman (djc) * |
Date: 2013-02-06 08:10 |
| Is there a particular reason for not upstreaming the PyObjC changes? |
|
|
| msg181510 - (view) |
Author: Matthias Klose (doko) * |
Date: 2013-02-06 12:29 |
| I'm planning to update the tip to the next libffi release candidate once it's released. Once this is checked in, maybe revisit the extra copy for OS X; an ABI issue with llvm/clang was identified in http://sourceware.org/ml/libffi-discuss/2013/msg00012.html and a work-around provided in http://sourceware.org/ml/libffi-discuss/2013/msg00021.html |
|
|
| msg181513 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2013-02-06 12:53 |
| Matthias: libffi_osx already contains the workaround you refer to. libffi_osx is the same as the variant of libffi included with PyObjC, and that is derived from the system libffi on OSX (IIRC the last time I merged their changes was around 10.7). The system libffi on OSX is a fork of the upstream one, at least partially because upstream didn't support darwin/i386 at the time of the fork. |
|
|
| msg181734 - (view) |
Author: Dirkjan Ochtman (djc) * |
Date: 2013-02-09 12:52 |
| libffi now has this fix: https://github.com/atgreen/libffi/commit/6a790129427121f7db2d876e7218a3104e6d2741 Can someone test with that? |
|
|
| msg181949 - (view) |
Author: Dirkjan Ochtman (djc) * |
Date: 2013-02-12 09:00 |
| libffi-3.0.12 has been released with that fix. Perhaps that should be included in future Python releases? |
|
|
| msg181959 - (view) |
Author: Matthias Klose (doko) * |
Date: 2013-02-12 14:34 |
| libffi-3.0.12 is now imported, tracked in issue #17192. |
|
|
| msg184888 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2013-03-21 17:21 |
| Fixed by libffi-3.0.13 import. |
|
|