Summary: | app-portage/gentoolkit-0.3.0.7 with dev-python/pypy-1.8-r2 - Fatal RPython error: BytecodeCorruption | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Ben Longbons <b.r.longbons> |
Component: | Tools | Assignee: | Portage Tools Team <tools-portage> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | b.r.longbons, nirbheek, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log for app-portage/gentoolkit
build.log with distutils_src_compile_pre_hook removed and pypy first in USE_PYTHON |
Description
Ben Longbons
2012-11-23 22:40:43 UTC
Since it works fine with CPython 2.7, I guess it's an issue with pypy. I suppose that we could simply use RESTRICT_PYTHON_ABIS to blacklist the pypy version(s) that choke on it. No, it's actually because the ebuild is running setup.py to modify the source, setting the version. This should be done when creating the sdist tarball instead. That way the .pyc file won't be created and confuse pypy. DISTUTILS_USE_SEPARATE_SOURCE_DIRECTORIES or DISTUTILS_IN_SOURCE_BUILD=1 in distutils-r1 can be used to prevent it in the current and -9999 ebuild. I have run multiple tests with the following USE_PYTHON and cannot reproduce this issue. USE_PYTHON="2.6 2.7 3.1 3.2 3.3 2.7-pypy-1.8 2.7-pypy-1.9" What is your output of "emerge -pv pypy:1.8" There are not any .pyc files created by running set_version, so I don't know how that can be causing the issue. $ emerge -pv pypy:1.8 [ebuild R ] dev-python/pypy-1.8-r1:1.8 USE="bzip2 doc jit ncurses ssl xml -examples -sandbox -shadowstack -sqlite" 14,578 kB Total: 1 package (1 reinstall), Size of downloads: 14,578 kB I also tried rebuilding gentoolkit so the issue hasn't just gone away for me. I might try building -r2 of pypy now (which was released December 1, i.e. after I reported this) ... it's not a fun build (but it is doable) with 3GB RAM. I wonder if there's any way you having 3.3 makes any difference? (btw - school's out for a few weeks so I'll be more responsive on nonweekends now.) still happens with pypy-1.8-r2 I still cannot reproduce even after rebuilding pypy with the same CFLAGS and USE flags as yours. However, let's prove or disprove the call to set_version. Please edit the gentoolkit-0.3.0.7 ebuild and comment out or remove the 5 lines of the distutils_src_compile_pre_hook function, run repoman manifest and re-install gentoolkit. All that this will affect is that you won't see accurate version numbers with the various --version or --help options. If it still fails, then I suspect that something is wrong with pypy-1.8 itself on your system. (In reply to comment #6) > However, let's prove or disprove the call to set_version. I tried that first, and then I also tried USE_PYTHON="2.7-pypy-1.8 2.7" so that it changed the order and tried to build with pypy first. It still fails :( > If it still fails, then I suspect that something is wrong with pypy-1.8 > itself on your system. Ok, so now what? I already rebuilt pypy once ... Can you attach the build.log of it failing with the distutils_src_compile_pre_hook function removed from the ebuild? Also, which version of gcc are you using to compile pypy? (In reply to comment #9) > Also, which version of gcc are you using to compile pypy? My system gcc is: gcc (Gentoo 4.6.3 p1.7, pie-0.5.2) 4.6.3 I have -march=native in CFLAGS, which on my system means: -march=k8-sse3 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=k8 (it was definitely an earlier gcc version at the time I compiled pypy-1.8-r1 on May 18, but I can't tell whether it was 4.6.x or not - I don't have the old pypy binary and that was before I had etckeeper) Created attachment 332698 [details]
build.log with distutils_src_compile_pre_hook removed and pypy first in USE_PYTHON
Nirbheek / python herd: Any ideas on how to troubleshoot this further. I cannot reproduce this issue on my system with pypy-1.8 and gentoolkit-0.3.0.7 I think we should basically remove pypy-1.8. I talked to upstream pypy and they said they're not interested in pre-2.0 bugs that have already been fixed in later releases. I don't have any particular reason to use 1.8; I just wanted to have more pythons to test my own software against. dev-python/pypy-1.8 is being removed from the tree in about 30 days and I cannot reproduce this issue. |