Created attachment 345714 [details] emerge --info, emerge -pqv, build.log and environment I do not know if compilers hate each other in general, but the title pretty much explain the problem...
Portage 2.1.11.62 (default/linux/amd64/13.0/desktop, gcc-4.7.2, glibc-2.17, 3.8.6-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.8.6-gentoo-x86_64-AMD_FX-tm-8150_Eight-Core_Processor-with-gentoo-2.2 KiB Mem: 8123860 total, 4518680 free KiB Swap: 12582908 total, 12579692 free Timestamp of tree: Tue, 16 Apr 2013 14:15:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.10.2-r2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.13.1 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.7.2-r1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.8 (virtual/os-headers) sys-libs/glibc: 2.17 Repositories: gentoo steam-overlay Proksima ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-ggdb -O2 -pipe -mtune=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-ggdb -O2 -pipe -mtune=native" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--quiet-build" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles installsources merge-sync news parallel-fetch protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://gentoo.arcticnetwork.ca/pub/gentoo/ http://gentoo.arcticnetwork.ca/ http://gentoo.gossamerhost.com rsync://gentoo.gossamerhost.com/gentoo-distfiles/ rsync://mirror.the-best-hosting.net/gentoo-distfiles http://mirror.the-best-hosting.net ftp://mirrors.tera-byte.com/pub/gentoo http://gentoo.mirrors.tera-byte.com/ rsync://mirrors.tera-byte.com/gentoo http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ ftp://mirror.csclub.uwaterloo.ca/gentoo-distfiles/" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/steam /usr/local/portage" SYNC="rsync://rsync.ca.gentoo.org/gentoo-portage"
Multiple ICEs in various files at once are usually sign of memory problems. Could you try to compile with MAKEOPTS="-j1"?
Just tried, took forever, but still segfaulting... :/
(In reply to comment #3) > Just tried, took forever, but still segfaulting... :/ After it fails, could you cd to workdir and run command that triggers error by hand appending '-save-temps' to it? It'll produce *.i file that I'd like you to attach to this bug. TIA!
Created attachment 345808 [details] Requested .i file after appending -save-temps to the faulty command The command that make the build segfault at makeopts="-j1" is: cd /var/tmp/portage/dev-lang/path64-1.0.0_pre20120223/work/path64-1.0.0_pre20120223_build/Xcompiler/src/libpscrt/pscrt-static-x86_64 && /var/tmp/portage/dev-lang/path64-1.0.0_pre20120223/work/path64-1.0.0_pre20120223_build/Xcompiler/bin/pathcc -c -o malloc_opt_c.o -m64 -DTARG_X8664 -I/var/tmp/portage/dev-lang/path64-1.0.0_pre20120223/work/path64-1.0.0_pre20120223_build/Xcompiler/src/include -I/var/tmp/portage/dev-lang/path64-1.0.0_pre20120223/work/path64/compiler/compiler/src/include -fpic -DHAVE_ALLOCA_H=1 -DX86_WHIRL_OBJECTS -DPATH64_ENABLE_PSCRUNTIME -D_SGI_SOURCE -D__GNU_BUG_WORKAROUND -DKEY -DFE_GNU_4_2_0 -D_LONGLONG -D_MIPSEL -DTARG_LINUX -D_GNU_SOURCE -DHOST_IS_BIG_ENDIAN=0 -DHOST_IS_LITTLE_ENDIAN=1 -D_LANGUAGE_C /var/tmp/portage/dev-lang/path64-1.0.0_pre20120223/work/path64/compiler/compiler/src/libpscrt/malloc_opt.c -O2 -DNDEBUG -mno-sse3 -save-temps However the file does not seem to contain much... If what I did was not appropriate, just tell me... ^^'
Probably not very helpful, but I had some fun with gdb and pinpointed the location of the segfault to be: /var/tmp/portage/dev-lang/path64-1.0.0_pre20120223/work/path64/compiler/compiler/src/driver/main.c line 675 Then it jumps to line 702, sees the error, cleanup and return.
(In reply to comment #5) > Created attachment 345808 [details] > Requested .i file after appending -save-temps to the faulty command > > The command that make the build segfault at makeopts="-j1" is: > /var/tmp/portage/dev-lang/path64-1.0.0_pre20120223/work/path64-1.0. > 0_pre20120223_build/Xcompiler/bin/pathcc -c -o malloc_opt_c.o -m64 > -DTARG_X8664 Somehow I've missed that it's stage1 pathcc that's ICEing rather than gcc itself. In that case there's not much that we can do here. Upstream usually wants user to compile path64 with either ekopath or path64 itself (USE="native"). You could try with latest git source of path64[1], but as you'll see it hasn't been developed much lately. [1] https://github.com/path64
Well, to be honest I do not need pathscale that much... Therefore I wouldn't really mind this bug to be marked as WONTFIX. That being said, is there anyone else that is able to emerge this package? Else it would make sense to mask it, no?
(In reply to comment #8) > Well, to be honest I do not need pathscale that much... Therefore I wouldn't > really mind this bug to be marked as WONTFIX. That being said, is there > anyone else that is able to emerge this package? Else it would make sense to > mask it, no? With another package. TCL. Attaching build log.
Created attachment 346102 [details] Failed build log of dev-lang/tcl-8.5.13-r1
(In reply to comment #9) > With another package. TCL. > > Attaching build log. Don't clobber the bug with random reports. Your bug doesn't concern path64 at all and furthermore is a duplicate of #361953
(In reply to comment #8) > Well, to be honest I do not need pathscale that much... Therefore I wouldn't > really mind this bug to be marked as WONTFIX. That being said, is there > anyone else that is able to emerge this package? Else it would make sense to > mask it, no? Path64 builds fine with previous versions of gcc and ekopath/path64 itself. Failing with gcc-4.7 doesn't validate masking. The only thing I can do to help is break bulding at pkg_setup when >=gcc-4.7 is detected.
removed from the tree