Created attachment 275171 [details] build.log i686-pc-linux-gnu-g++ -c -O2 -march=i686 -pipe -Wall -fPIC -fexceptions -frtti -I/usr/include/python3.2 -I/usr/share/python3.2/CXX -I/usr/include/python3.2 -I/usr/inc lude/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_processi ng.o pysvn_arg_processing.cpp /usr/share/python3.2/CXX/cxx_extensions.cxx: In member function 'Py::PythonType& Py::PythonType::supportHash()': /usr/share/python3.2/CXX/cxx_extensions.cxx:576:22: error: invalid conversion from 'long int (*)(PyObject*)' to 'Py_hash_t (*)(PyObject*)' Compile pysvn_converters.o i686-pc-linux-gnu-g++ -c -O2 -march=i686 -pipe -Wall -fPIC -fexceptions -frtti -I/usr/include/python3.2 -I/usr/share/python3.2/CXX -I/usr/include/python3.2 -I/usr/inc lude/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_converters.o pysvn_converters.cpp make: *** [cxx_extensions.o] Error 1 make: *** Waiting for unfinished jobs.... emake failed * ERROR: dev-python/pysvn-1.7.5 failed (compile phase): * Building failed with CPython 3.2 in building() function [ebuild R ] dev-python/pycxx-6.2.3-r2 USE="-doc -examples" Portage 2.1.9.50 (default/linux/x86/10.0, gcc-4.5.2, glibc-2.13-r2, 2.6.25-hardened-r13 x86_64) ================================================================= System uname: Linux-2.6.25-hardened-r13-x86_64-Dual_Core_AMD_Opteron-tm-_Processor_280-with-gentoo-2.0.2 Timestamp of tree: Mon, 30 May 2011 10:00:01 +0000 app-shells/bash: 4.2_p10 dev-lang/python: 2.7.1-r1, 3.2 dev-util/cmake: 2.8.4-r1 sys-apps/baselayout: 2.0.2 sys-apps/openrc: 0.8.2-r1 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.1-r1 sys-devel/binutils: 2.21 sys-devel/gcc: 4.5.2 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82 sys-kernel/linux-headers: 2.6.38 (virtual/os-headers) sys-libs/glibc: 2.13-r2 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm gpm iconv icu ipv6 modules mudflap ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline session ssl subversion sysfs tcpd threads unicode x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="braindump flow karbon kexi kpresenter krita tables words" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="dummy" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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.
