emerge aspell-en segfaults when compiling with gcc-4.0 >>> Source unpacked. /var/tmp/portage/aspell-en-6.0.0/work/aspell6-en-6.0-0 Finding Dictionary file location ... /usr/lib/aspell-0.60 Finding Data file location ... /usr/lib/aspell-0.60 /usr/bin/prezip-bin -d < en-common.cwl | /usr/bin/aspell --lang=en create master ./en-common.rws /bin/sh: line 1: 11495 Done /usr/bin/prezip-bin -d <en-common.cwl 11496 Segmentation fault | /usr/bin/aspell --lang=en create master ./en-common.rws make: *** [en-common.rws] Error 139 Portage 2.0.51.22-r2 (default-linux/ppc/2005.1/ppc, gcc-4.0.1, glibc-2.3.5.20050722-r0, 2.6.12-gentoo-r9 ppc) ================================================================= System uname: 2.6.12-gentoo-r9 ppc 7450, altivec supported Gentoo Base System version 1.12.0_pre6 dev-lang/python: 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="ppc ~ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -mtune=7450 -maltivec -mabi=altivec -pipe" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mtune=7450 -maltivec -mabi=altivec -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig candy ccache cvs distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://open-systems.ufl.edu/mirrors/gentoo http://mirror.datapipe.net/gentoo" LDFLAGS="-Wl,-O1 -Wl,--sort-common" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/gentoo" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="ppc X alsa altivec berkdb bitmap-fonts cdrw crypt cups dvd dvdread emboss fam fortran gif gnome gpm gtk gtk2 imagemagick ipv6 jpeg libwww motif mp3 mpeg ncurses nls nptl nptlonly nsplugins ogg oggvorbis opengl pam pdflib perl png python readline spell ssl tcpd tiff truetype truetype-fonts type1-fonts unicode userlocales vorbis xml2 xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LINGUAS, MAKEOPTS
Could you please try the gcc-4.0.2_pre ebuild in the tree and see if this is still a problem?
Can someone using gcc-4.0.2-r1 on ppc please confirm if this is still a problem or not? I can not reproduce it on the ppc dev box, but I'd like to be sure.
I can reproduce this with aspell 0.60.4, but it doesn't seem to segfault with aspell-0.50.5-r4
Alright "-maltivec -mabi=altivec" seem to be the culprit. As far as I can tell its generating wrong code: #0 0x375343c4 in free_norm_table<acommon::FromUniNormEntry> (d=0x1) at convert.cpp:243 #1 0x375343b4 in free_norm_table<acommon::FromUniNormEntry> (d=0x1007b5f8) at convert.cpp:245 #2 0x37537594 in ~NormTables (this=0x1007aac8) at convert.cpp:485 #3 0x374fba48 in acommon::GlobalCacheBase::release (this=0x37638940, d=0x1007aac8) at cache.cpp:45 #4 0x374fbab8 in acommon::release_cache_data (cache=0x37638940, d=0x1007aac8) at cache.cpp:67 #5 0x10023e78 in acommon::Cacheable::release (this=0x1007aac8) at cache.hpp:37 #6 0x3753ddcc in acommon::CachePtr<acommon::NormTables>::reset ( this=0x1007a6e8, p=0x0) at cache.hpp:49 #7 0x3753de14 in ~CachePtr (this=0x1007a6e8) at cache.hpp:63 #8 0x37537be8 in ~Convert (this=0x1007a6d0) at convert.cpp:983 #9 0x10023f8c in ~ConvObj (this=0x10078178) at convert.hpp:229 #10 0x375b6004 in ~Language (this=0x10078110) at language.hpp:63 #11 0x374fba48 in acommon::GlobalCacheBase::release (this=0x37638a68, d=0x10078110) at cache.cpp:45 The 0x1 does not look right to me at all. No idea how to reduce this to a testcase to send upstream though.
I have that problem too. In fact applications that use aspell crash when they need to check spelling. it's a combination of this bug and bug #96794 - not sure if they are related though. I tried to compile aspell without -maltivec -mabi=altivec and it still results in the same problems when emerging some dictionary.
*** Bug 118684 has been marked as a duplicate of this bug. ***
Now that I compiled it with gcc-3.4.4 it works, but with gcc-4.0.2 it doesn't work for me even without -maltivec -mabi=altivec.
gcc-4.1 seems to fix the issue if you filter the altivec flags.
I compiled it with sys-devel/gcc-4.1.0_beta20060120 and it compiled just fine, alitvec, -mabi=altivec, and -maltivec included. I made a simple document with lots of typos and ran `aspell -c test.txt` on it and it ran ok.
(In reply to comment #9) > I compiled it with sys-devel/gcc-4.1.0_beta20060120 and it compiled just fine, > alitvec, -mabi=altivec, and -maltivec included. In my case, using sys-devel/gcc-4.1.0, CFLAGS="-Os -mcpu=G4 -mtune=G4 -maltivec -mtune=altivec -fno-strict-aliasing -Wall -pipe" in /etc/make.conf. (It's just for compilation error detecting.) Then, like running "emerge -e world". When emerging app-text/aspell-0.60.4 in official tree, the ebuild filered -maltivec and -mabi=altivec at the moment. So, app-text/aspell-0.60.4 was compiled with CFLAGS="-Os -mcpu=G4 -mtune=G4 -fno-strict-aliasing -Wall -pipe". It seems no compilation errors. But libtool wornings are, though. And then, like "emerge -e world" will emerge app-dicts/aspell-en-6.0.0 as next step. Its emerge process failed with the completely same error messages in first report. According to the bug #122855 (it might alpha specific, though), -Os in CFLAGS may produce aspell's segfault. This report suggests to use -O2 instead of -Os by replace-flags. So, I've tried to do it. Therefore, I've modified ebuild and emerge app-text/aspell-0.60.4 with CFLAGS="-O2 -mcpu=G4 -mtune=G4 -fno-strict-aliasing -Wall -pipe". Then, emerge app-dicts/aspell-en-6.0.0. But, it reproduces segfault, too.
Created attachment 81838 [details] emerge --info, emerge --pretend, emege failed outputs are "cat"ed
Well, this is fixed for now by filtering altivec for just this package. I'll keep an eye on this for 4.1.1.
*** Bug 127083 has been marked as a duplicate of this bug. ***
lu_zero says this is fixed now.
