Summary: | dev-python/pycairo-1.10.0-r3 fails to build for pypy | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander E. Patrakov <patrakov> |
Component: | [OLD] Library | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | Martin.vGagern |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alexander E. Patrakov
2012-12-19 17:19:49 UTC
Same here. This is a real oddity. On first inspection, the finding is something wrong with your systems. In fact, that does hold. However, on closer inspection, the problems are doubled. "Please take all my reports with a grain of salt" serves only to muddy the waters. Firstly, there is something I can't define that is 'wrong' in your systems. My system effectively emerges the package without issue. Secondly, pypy's capacity to pass tests has been actually broken by the most recent revbump changes, more like shattered. This finding is one that 'came out in the wash'. Closing it invalid, at the same time I shall have to restrict pypy from ABIS, its cause, stated above, unrelated to the nature of this filed bug Thanks for confirming that it is a local issue. I will investigate further in a chroot without this overlay. sure, please post cause if you discover if only for the sake of M. von Gagern Sorry Ian, I have to reopen this.
The difference between the working and the failed cases is that the working case is -r2 and the failing is -r3 with your ABI restriction undone (same results both with and without my overlay, so let's ignore the system with the overlay from now on). And, honestly, I don't understand why it worked at all in the -r2 case. Can you reproduce the failure by unpacking py2cairo manually and running this command?
EPYTHON=pypy-c1.9 ./waf --prefix=/usr --libdir=/usr/lib64 configure
Here is what happens. Waf unpacks itself. Then it somehow imports waflib/Tools/python.py, which contains this code (slightly simplified):
v='prefix SO LDFLAGS LIBDIR LIBPL INCLUDEPY Py_ENABLE_SHARED MACOSX_DEPLOYMENT_TARGET LDSHARED CFLAGS'.split()
lst=conf.get_python_variables(["get_config_var('%s')"%x for x in v],['from distutils.sysconfig import get_config_var'])
dct=dict(zip(v,lst))
all_flags=dct['LDFLAGS']+' '+dct['LDSHARED']+' '+dct['CFLAGS']
The second line forks a separate python process that runs this program:
from distutils.sysconfig import get_config_var
print(repr(get_config_var('prefix')))
print(repr(get_config_var('SO')))
print(repr(get_config_var('LDFLAGS')))
print(repr(get_config_var('LIBDIR')))
print(repr(get_config_var('LIBPL')))
print(repr(get_config_var('INCLUDEPY')))
print(repr(get_config_var('Py_ENABLE_SHARED')))
print(repr(get_config_var('MACOSX_DEPLOYMENT_TARGET')))
print(repr(get_config_var('LDSHARED')))
print(repr(get_config_var('CFLAGS')))
On pypy, distutils.sysconfig is /usr/lib/pypy1.9/lib-python/2.7/distutils/sysconfig.py which imports /usr/lib/pypy1.9/lib-python/2.7/distutils/sysconfig_pypy.py . The implementation of get_config_var is straightforward, and you can see that none of the variables that the test program asks for are defined:
>>>> from distutils.sysconfig import get_config_vars
>>>> get_config_vars()
{'LIBDIR': '/usr/lib64/pypy1.9/lib', 'EXE': '', 'SO': '.pypy-19.so', 'SOABI': ''}
So no wonder that the test program attempted to add None and ' '. The question is, I repeat, how it worked at all in -r2.
Removal of the following line from -r3 allows it to build: WAF_BINARY="./waf" Indeed, yay for strange buildsystems :( OK, found why it worked (by stracing the whole build process). The tests are different. With WAF_BINARY="./waf" in place: print(repr(get_config_var('LDFLAGS'))) Without it: print(repr(get_config_var('LDFLAGS') or '')) So something patches the tests without WAF_BINARY and doesn't patch in the other case. The bug is now fully understood. In -r2, waf-1.6.4 from pycairo was used for compiling both pycairo and py2cairo. In -r3, by exporting WAF_BINARY="./waf", you downgraded py2cairo's waf to the buggy version 1.6.3, that's why the failure. A good-enough fix would be to copy waf from pycairo to py2cairo. (In reply to comment #8) > The bug is now fully understood. In -r2, waf-1.6.4 from pycairo was used for > compiling both pycairo and py2cairo. In -r3, by exporting > WAF_BINARY="./waf", you downgraded py2cairo's waf to the buggy version > 1.6.3, that's why the failure. > > A good-enough fix would be to copy waf from pycairo to py2cairo. Nice detective work. Another approach would be to replace waf for both packages with the latest compatible version. We could just add https://waf.googlecode.com/files/waf-1.6.11 to SRC_URI and copy it into place in src_prepare. Actually, installing with pypy doesn't work anyway; waf installs the modules for pypy in /usr/lib/python2.7/site-packages instead of /usr/lib/pypy1.9/site-packages. * Installation of dev-python/pycairo-1.10.0-r3 with PyPy 1.9 (Python 2.7)... "./waf" --destdir="/tmp/portage/dev-python/pycairo-1.10.0-r3/image/" install ./options() Waf: Entering directory `/tmp/portage/dev-python/pycairo-1.10.0-r3/work/pycairo-1.10.0-2.7-pypy-1.9/build_directory' ./build() src/build() - install /tmp/portage/dev-python/pycairo-1.10.0-r3/image/usr/include/pycairo/pycairo.h (from src/pycairo.h) + install /tmp/portage/dev-python/pycairo-1.10.0-r3/image/usr/lib64/python2.7/site-packages/cairo/_cairo.pypy-19.so (from build_directory/src/_cairo.pypy-19.so) + install /tmp/portage/dev-python/pycairo-1.10.0-r3/image/usr/lib64/pkgconfig/pycairo.pc (from pycairo.pc) Waf: Leaving directory `/tmp/portage/dev-python/pycairo-1.10.0-r3/work/pycairo-1.10.0-2.7-pypy-1.9/build_directory' - install /tmp/portage/dev-python/pycairo-1.10.0-r3/image/usr/lib64/python2.7/site-packages/cairo/__init__.py (from src/__init__.py) 'install' finished successfully (0.069s) Until waf actually supports pypy, nothing we can do here. |