Summary: | [4.3] dev-python/pygtk-2.12.? segfaults on ppc64 (-fschedule-insns) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrew John Hughes <gnu_andrew> |
Component: | [OLD] Library | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ppc64, python, SebastianLuther, siarhei.siamashka, toolchain |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | PPC64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 302468 | ||
Bug Blocks: |
Description
Andrew John Hughes
2008-10-14 09:55:15 UTC
1) Please specify the version and revision of dev-python/pygtk in the summary. 2) You appear to have two versions of dev-lang/python installed - in which one did you run `import gtk'? 3) Also, did you run python-updater after installing dev-lang/python-2.5*? I have encountered the same problem with pygtk. It is fixable in my case by reducing optimization level to "-O1" or adding "-fno-schedule-insns" to CFLAGS. Looks like there is a high chance that it is caused by an invalid code generation problem in gcc 4.3. This might be interesting to investigate before gcc 4.3 stabilization. Unfortunately I don't know ppc64 assembly yet and building pygtk is a major pain on ps3 (gcc uses swap extensively and build takes a huge amount of time). Portage 2.2_rc23 (default-linux/ppc/ppc64/2007.0/64bit-userland/desktop/970, gcc-4.3.3, glibc-2.9_p20081201-r2, 2.6.29-rc4-02873-g2eb4b97 ppc64) ================================================================= System uname: Linux-2.6.29-rc4-02873-g2eb4b97-ppc64-Cell_Broadband_Engine,_altivec_supported-with-glibc2.3 Timestamp of tree: Sat, 07 Mar 2009 12:30:01 +0000 app-shells/bash: 3.2_p39 dev-lang/python: 2.5.2-r7 dev-python/pycrypto: 2.0.1-r8 sys-apps/baselayout: 1.12.12 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="ppc64" CBUILD="powerpc64-unknown-linux-gnu" CFLAGS="-O2 -pipe -mcpu=cell -mtune=cell -mabi=altivec" CHOST="powerpc64-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -mcpu=cell -mtune=cell -mabi=altivec" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages nostrip parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="ru_RU.UTF-8" LDFLAGS="" 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/portage/local/layman/lxde /usr/portage/local/layman/cell" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl alsa altivec berkdb bluetooth cairo cdr cli cracklib crypt dbus dri dvd dvdr eds emboss encode fam fbcon firefox fortran gdbm gif gpm gstreamer gtk hal iconv isdnlog jpeg kde ldap lzma mad midi mikmod mp3 mpeg mudflap ncurses nls nptl nptlonly ogg openmp pam pcre perl png ppc64 pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl ssl svg tcpd truetype unicode vorbis wifi xml xorg xulrunner xv zlib" 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 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" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev mach64 mga nv r128 radeon s3 vega vga" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS *** Bug 272214 has been marked as a duplicate of this bug. *** More info present now. Assigning to maintainer and CC'ing toolchain and ppc64 since it might be a misscompilation. A small update to this bug if anybody is interested. The problem is somewhere in the huge autogenerated file 'gtk.c' (4MB, 120K lines). I had a hope to use a new '#pragma GCC optimize' gcc 4.4 feature to bisect this file and pinpoint the place where the invalid code is generated. But the bug is not reproducible with gcc 4.4.0-r1 anymore. That said, when compiling this huge file, my PS3 swap quite heavily and it takes insane amount of time to build pygtk. So it is not very productive for me to do any kind of experiments with this bug. Let's hope that gcc 4.4 stabilizes soon on ppc64 :-) what about pygtk 2.14 ? (In reply to comment #6) > what about pygtk 2.14 ? For me this problem is reproducible with any version of pygtk in portage and any gcc 4.3.x (just tested 4.3.4 too). But I would surely like to get a confirmation from somebody else. Because this looks like a rather serious problem and showstopper on ppc64, unless it only happens in my configuration (maybe running gcc in low memory conditions somehow triggers it, and having enough memory would solve it). On the other hand, gcc 4.4 seems to generate much faster code for cell PPU (up to ~20% speedup or even more on some applications when compared to gcc 4.3 without "-fno-schedule-insns" workaround). So I'm not going to go back to 4.3 anyway. Maybe we could close this now that gcc-4.4 is in stable... :-/ (In reply to comment #8) > Maybe we could close this now that gcc-4.4 is in stable... :-/ > you are mistaken, ppc* doesnt have gcc-4.4 stable True :-|, sorry for the noise (In reply to comment #10) > True :-|, sorry for the noise > now it is :) closing as solved by gcc-4.4 |