Summary: | dev-python/pycxx fails to build pysvn-1.7.5 with python-3.2 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paweł Hajdan, Jr. (RETIRED) <phajdan.jr> |
Component: | [OLD] Library | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bircoph, bug, dflogeras2, floppym, hwoarang, tdalman |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://sourceforge.net/tracker/?func=detail&aid=3464317&group_id=3180&atid=303180 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 409029 | ||
Bug Blocks: | 292402 | ||
Attachments: | build.log |
Description
Paweł Hajdan, Jr. (RETIRED)
2011-05-30 11:08:16 UTC
As a quick fix I added -fpermissive to package's CXXFLAGS. It works this way. I can't reproduce this bug. Which version of dev-python/pycxx do you use? dev-python/pycxx-6.2.3-r2 was used. However, I care no longer, because both pysvn and pycxx were removed by depclean after full upgrade (-DNu) was finished. (In reply to comment #2) > I can't reproduce this bug. Which version of dev-python/pycxx do you use? I included that info in the original report: > [ebuild R ] dev-python/pycxx-6.2.3-r2 USE="-doc -examples" (In reply to comment #2) > I can't reproduce this bug. Which version of dev-python/pycxx do you use? same here testuser@archtester ~/patches $ eselect python list Available Python interpreters: [1] python2.7 [2] python3.1 [3] python3.2 * [ebuild R ] dev-python/pycxx-6.2.3-r2 USE="-doc -examples" 0 kB >>> Emerging (1 of 1) dev-python/pycxx-6.2.3-r2 >>> Installing (1 of 1) dev-python/pycxx-6.2.3-r2 Paweł, can you still reproduce this? Otherwise, I'd like to close this. (In reply to comment #6) > Paweł, can you still reproduce this? Otherwise, I'd like to close this. Yes, I can still repro on a stable x86 system. Have you tried to reproduce this? I'm using pycxx-6.2.3-r2, currently the only version of pycxx, and subversion-1.6.17-r7, latest stable on x86. Note that I had to keyword-unmask python-3.2 to test this (and I've ran python-updater of course). albeit I'm the novice, I can show what but I can't say why. gentoo64 pycxx # qlist pycxx | grep site-pack /usr/lib64/python2.6/site-packages/CXX/__init__.py /usr/lib64/python2.6/site-packages/CXX-6.2.0-py2.6.egg-info /usr/lib64/python3.2/site-packages/CXX/__init__.py /usr/lib64/python3.2/site-packages/CXX-6.2.0-py3.2.egg-info This pulls up at /usr/share/python3.2/CXX/cxx_extensions.cxx: In member function 'Py::PythonType& Py::PythonType::supportHash()': On mine, effectively builds. gentoo64 pycxx # grep pysvn_arg_processing.cpp /mnt/gen2/tmpdir/portage/dev-python/pysvn-1.7.5/temp/build.log x86_64-pc-linux-gnu-g++ -c -march=athlon64 -fomit-frame-pointer -pipe -O3 -Wall -fPIC -fexceptions -frtti -I/usr/include/python2.6 -I/usr/share/python2.6/CXX -I/usr/include/python2.6 -I/usr/include/subversion-1 -I/usr/include/apr-1 -I. -DNDEBUG -DPYCXX_PYTHON_2TO3 -Dinit_pysvn=init_pysvn_2_6 -Dinit_pysvn_d=init_pysvn_2_6_d -o pysvn_arg_processing.o pysvn_arg_processing.cpp from pysvn_arg_processing.cpp:16: pysvn_arg_processing.cpp:115:32: instantiated from here x86_64-pc-linux-gnu-g++ -c -march=athlon64 -fomit-frame-pointer -pipe -O3 -Wall -fPIC -fexceptions -frtti -I/usr/include/python3.2 -I/usr/share/python3.2/CXX -I/usr/include/python3.2 -I/usr/include/subversion-1 -I/usr/include/apr-1 -I. -DNDEBUG -DPYCXX_PYTHON_2TO3 -DPyInit__pysvn=PyInit__pysvn_3_2 -DPyInit__pysvn_d=PyInit__pysvn_3_2_d -o pysvn_arg_processing.o pysvn_arg_processing.cpp Now you more knowledgeable than I may know why, but the what is plain to see. Pawel's system goes to the cxx_extensions.cxx file in the option of /usr/share/python3.2. Mine goes to the option of -I/usr/share/python2.6/CXX. The deficit is in python3.2 supporting the Py::PythonType& Py::PythonType::supportHash()' or such. Re-direct the build in Pawel's build to the python2.6 for pycxx, and hey presto. The issue is pysvn building with python3.2, not pycxx gentoo64 pycxx # head pycxx-6.2.3-r2.ebuild # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/dev-python/pycxx/pycxx-6.2.3-r2.ebuild,v 1.4 2011/05/28 11:55:47 ranger Exp $ EAPI="3" SUPPORT_PYTHON_ABIS="1" RESTRICT_PYTHON_ABIS="*-jython" inherit eutils distutils It's not restricted from any CPython. I'm not suggesting a patch this time, especially when it's another package!!!! Python team please review. going out on a limb but why not. The package pycxx is sadly lacking the following. PYTHON_DEPEND="*::3.2" or PYTHON_DEPEND="*" which equips it for python3 (In reply to comment #9) If PYTHON_DEPEND is not set, then distutils.eclass adds dependency on dev-lang/python. (python.eclass from Progress Overlay in EAPI="4-python" in packages supporting installation for multiple Python ABIs sets default PYTHON_DEPEND, if PYTHON_DEPEND is not set.) I was able to reproduce the problem in an x86 chroot. Python 3.2 introduces the Py_hash_t type, which ultimately translates to a ssize_t. This is a 64-bit data type on both x86 and amd64. x86 has 32-bit longs, whereas amd64 has 64-bit longs, allowing for an implicit conversion from Py_hash_t to long. I have committed a patch and a revbump (pycxx-6.2.3-r3). This resolves the problem in my chroot. Please test this before I close it. This actually has nothing to do with 32 vs 64 bit ssize_t; that was incorrect. It is actually much simpler: on x86, ssize_t is an int; on amd64, ssize_t is a long. It's just a type mismatch. This seems to be fixed. Reopen if needed *** Bug 407053 has been marked as a duplicate of this bug. *** Stable 1.7.5 is still broken, and there are reports about 1.7.6 also being broken. Anyway, please push the fix to stable before calling it fixed. (In reply to comment #15) > Stable 1.7.5 is still broken, and there are reports about 1.7.6 also being > broken. There are no such reports, because it was bug in <dev-python/pycxx-6.2.3-r3, not in dev-python/pysvn. File separate bug with stabilization request instead of reopening already fixed bugs. As for this package, the dependencies could be set to >=dev-python/pycxx-6.2.3-r3. That would be this fix for this bug, no ? (In reply to comment #17) We can't do that until pycxx-6.2.3-r3 is stable; repoman would throw a fit. pycxx-6.2.3-r3 is stable, so we should be all set here. |