| Summary: | dev-python/pypy-2.5.1 fails during install on amd64 (likely due to ncurses-6) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tobias Klausmann (RETIRED) <klausman> |
| Component: | Current packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexandref75, marienz, uzytkownik2 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | pypy-2.5.1 build log | ||
|
Description
Tobias Klausmann (RETIRED)
2015-08-14 11:35:37 UTC
Created attachment 408978 [details]
pypy-2.5.1 build log
Well, you can't expect Python projects like cffi not to be braindead. 'm afraid this won't be fixed until upstream fixes it in hg, and we backport. I'm getting what's probably the same failure. This is especially interesting because this is a USE=-ncurses build (and pypy builds fine, the ebuild fails in "Generating caches and byte-compiling").
We fail doing:
"${PYTHON}" -c "import _curses" || die "Failed to import _curses (cffi)"
This is a USE=-ncurses build, so I'm a bit puzzled this runs at all. But your build is USE=ncurses, so I'm guessing that doesn't matter.
MEVENT as defined in /usr/include/curses.h (from ncurses-6) is indeed size 20, not 24 (confirmed with a small test program). MEVENT from curses-5.9 is size 24 (mmask_t changed from "unsigned long" to "unsigned").
Ah, and looking at pypy's source tree, it calls cffi's cdef (in pypy-2.5.1-src/lib_pypy/_curses.py) with (among other things) "typedef unsigned long mmask_t;", which is now wrong. It still does this in the current source tree, although things have moved around a little (especially in commit c4c3a9d60c79).
Looking at the cffi docs, cffi should support "..." in the typedef to solve this exact problem (it causes it to defer to the compiler). But that requires some changes to how cffi is used, and might not be supported by the cffi in this version of pypy (haven't tried, but it's a bad sign that "typedef int..." does not occur in the source tree).
This code has also moved around a bit in the next pypy release, so I'm going to try that one rather than trying to fix this one. I don't think it'll actually work out of the box, but it's probably easier/saner to patch there.
It might make sense for Gentoo to patch the typedef in pypy-2.5.1 based on the version of curses we're linking against (ugly, but a better fix is *probably* not trivial, if I understand cffi correctly).
Correction: pypy-2.6.0 should work. Upstream commit 2ac1dfd25d5b ("Use the new syntax "typedef int... foo_t" where appropriate") fixes this the way I expected, but it doesn't apply to pypy-2.5. I'm building it now to confirm.
(In reply to Marien Zwart from comment #3) > I'm getting what's probably the same failure. This is especially interesting > because this is a USE=-ncurses build (and pypy builds fine, the ebuild fails > in "Generating caches and byte-compiling"). > > We fail doing: > "${PYTHON}" -c "import _curses" || die "Failed to import _curses (cffi)" > > This is a USE=-ncurses build, so I'm a bit puzzled this runs at all. But > your build is USE=ncurses, so I'm guessing that doesn't matter. Fixed USE=-ncurses not to gen curses. Also accidental USE=-gdbm gdbm gen in 2.6.0. Hope this doesn't break anything. I've also forced ncurses:5/5 for now in the source ebuilds. > MEVENT as defined in /usr/include/curses.h (from ncurses-6) is indeed size > 20, not 24 (confirmed with a small test program). MEVENT from curses-5.9 is > size 24 (mmask_t changed from "unsigned long" to "unsigned"). > > Ah, and looking at pypy's source tree, it calls cffi's cdef (in > pypy-2.5.1-src/lib_pypy/_curses.py) with (among other things) "typedef > unsigned long mmask_t;", which is now wrong. It still does this in the > current source tree, although things have moved around a little (especially > in commit c4c3a9d60c79). > > Looking at the cffi docs, cffi should support "..." in the typedef to solve > this exact problem (it causes it to defer to the compiler). But that > requires some changes to how cffi is used, and might not be supported by the > cffi in this version of pypy (haven't tried, but it's a bad sign that > "typedef int..." does not occur in the source tree). > > This code has also moved around a bit in the next pypy release, so I'm going > to try that one rather than trying to fix this one. I don't think it'll > actually work out of the box, but it's probably easier/saner to patch there. > > It might make sense for Gentoo to patch the typedef in pypy-2.5.1 based on > the version of curses we're linking against (ugly, but a better fix is > *probably* not trivial, if I understand cffi correctly). I'm afraid fixing just one obvious issue isn't going to fix ABI compatibility completely. And certainly I'm not the one who will writing that patch. Confirmed 2.6 works. Also more or less confirmed the correct fix (the "..." feature I mentioned) requires cffi support introduced in pypy-2.6. I believe making this work in 2.6 would be quite ugly. I'd recommend either having older pypy depend on old curses (like you did), or applying an unconditional patch to pypy to use the new typedef and depend on new curses. Hopefully pypy-2.6 can be unleashed upon the world not too long from now, which fixes this properly. Thanks for confirming it. I'm going to revert the dep change in 2.6.0 and unmask it now. commit 60f4e6436345685d70cbb30fd4790337c4e2e659 Author: Michał Górny <mgorny@gentoo.org> Date: Sat Aug 15 09:11:10 2015 +0200 profiles: Unmask dev-python/pypy-2.6.0 The new version was p.masked long enough, and it is required for sys-libs/ncurses upgrade. commit 2fd64a3588cc4436392871c0001d13f5e7eb0d77 Author: Michał Górny <mgorny@gentoo.org> Date: Sat Aug 15 09:10:46 2015 +0200 dev-python/pypy-2.6.0: restore more flex ncurses dep, confirmed working Allow the newer sys-libs/ncurses version as it has been confirmed to work with pypy-2.6.0. Bug: https://bugs.gentoo.org/show_bug.cgi?id=557540#c6 Package-Manager: portage-2.2.20 *** Bug 557894 has been marked as a duplicate of this bug. *** |
