Created attachment 633572 [details] gcc-build-logs INFO: compile Compiling gcc (bootstrap-lean)... ERROR: compile ERROR: sys-devel/gcc-9.3.0::gentoo failed (compile phase): emake failed If you need support, post the output of `emerge --info '=sys-devel/gcc-9.3.0::gentoo'`, the complete build log and the output of `emerge -pqv '=sys-devel/gcc-9.3.0::gentoo'`. The complete build log is located at '/var/tmp/portage/sys-devel/gcc-9.3.0/temp/build.log'. The ebuild environment file is located at '/var/tmp/portage/sys-devel/gcc-9.3.0/temp/environment'. Working directory: '/var/tmp/portage/sys-devel/gcc-9.3.0/work/build' S: '/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0' ERROR: other
Created attachment 633574 [details] emerge --info
The build error is: """ libtool: compile: /var/tmp/portage/sys-devel/gcc-9.3.0/work/build/./gcc/xg++ -B/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/./gcc/ -nostdinc++ -nostdinc++ -I/var/tmp/port age/sys-devel/gcc-9.3.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/x86_64-pc-linux-gnu/libstdc+ +-v3/include -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libstdc++-v3/libsupc++ -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libstdc++-v3/include/backward -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libstdc++-v3/testsuite/util -L/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/va r/tmp/portage/sys-devel/gcc-9.3.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/lib supc++/.libs -B/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/x86_64-pc-linux-gn u/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys -include -fchecking=1 -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libitm -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libitm/config/lin ux/x86 -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libitm/config/linux -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libitm/config/x86 -I/var/tmp/portage/sy s-devel/gcc-9.3.0/work/gcc-9.3.0/libitm/config/posix -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libitm/config/generic -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/g cc-9.3.0/libitm -mrtm -pthread -Wall -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -march=native -pipe -O2 -D_GNU_SOURCE -MT method-serial.lo -MD -MP -MF .deps/method-serial.Tpo -c /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libitm/method-serial.cc -o method-serial.o >/dev/null 2>&1 make[4]: *** [Makefile:678: method-serial.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... """ I'd surprised stdout and stderr is redirected to /dev/null. Try to run that command from ebuilds' workdir without '>/dev/null 2>&1' to get the error.
cd-ing to build directory and executing make -j1 works. I assume this is a parallel build issue.
does it work if you attempt to emerge gcc again?
(In reply to Sergei Trofimovich from comment #4) > does it work if you attempt to emerge gcc again? Not with Makeoptions -j4. I tipple checked that.
That's unfortunate. I can't find any clue from build.log. It looks perfectly normal except that build error without any details around it. Could it be some environment issue? Like filled up disk space, accidentally wiped /tmp/, OOM of gcc or maybe RAM stability problems? Closing WORKSFORME meanwhile.
(In reply to Sergei Trofimovich from comment #6) > That's unfortunate. I can't find any clue from build.log. It looks perfectly > normal except that build error without any details around it. > > Could it be some environment issue? Like filled up disk space, accidentally > wiped /tmp/, OOM of gcc or maybe RAM stability problems? Closing WORKSFORME > meanwhile. What I did: 1. masked gcc 9.3 2. cold reboot 3. rebuilt toolchain (gcc 9.2, binutils, glibc, gcc) 4. rebuilt the whole system (world) 5. re-emerged gcc 9.2 6. tested gcc, compiled binaries fine -> No issues. Everything built fine without errors. 7. cold reboot 8. unmasked 9.3 9. emerge -avuDN world -> emake failed, not able to build 9.3 The system is well administrated and in perfect shape. Question: Why does everything build nicely except gcc 9.3.0? (and it has built every gcc since version 6 or so …)
For now, it seems there is a memory problem. I changed the status to invalid for now. - age/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer -I /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/../libbacktrace -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -g -march=native -pipe -O2 -MT cp-demangle.lo -MD -MP -MF .deps/cp-demangle.Tpo -c -o cp-demangle.lo `test -f '../../libiberty/cp-demangle.c' || echo '/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/libbacktrace/'`../../libiberty/cp-demangle.c libtool: compile: /var/tmp/portage/sys-devel/gcc-9.3.0/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/libbacktrace -I.. -I /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/../include -I /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/../libgcc -I ../../libgcc -I .. -I /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer -I /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/../libbacktrace -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -g -march=native -pipe -O2 -MT cp-demangle.lo -MD -MP -MF .deps/cp-demangle.Tpo -c /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/libbacktrace/../../libiberty/cp-demangle.c -fPIC -DPIC -o .libs/cp-demangle.o cc1plus: out of memory allocating 166248 bytes after a total of 43786240 bytes cc1plus: out of memory allocating 24082176 bytes after a total of 15208448 bytes cc1plus: out of memory allocating 177600 bytes after a total of 44388352 bytes make[4]: *** [Makefile:678: method-ml.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... /bin/bash ../libtool --tag=CXX --mode=compile /var/tmp/portage/sys-devel/gcc-9.3.0/work/build/./gcc/xgcc -shared-libgcc -B/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/./gcc -nostdinc++ -L/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-9.3.0/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/libbacktrace -I.. -I /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/../include -I /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/../libgcc -I ../../libgcc -I .. -I /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer -I /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/../libbacktrace -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wcast-qual -Wno-unused-parameter -fno-rtti -fno-exceptions -std=gnu++11 -g -march=native -pipe -O2 -D_GNU_SOURCE -MT bridge.lo -MD -MP -MF .deps/bridge.Tpo -c -o bridge.lo /var/tmp/portage/sys-devel/gcc-9.3.0/work/gcc-9.3.0/libsanitizer/libbacktrace/bridge.cc make[4]: *** [Makefile:678: method-gl.lo] Error 1 @
Maybe try sys-apps/memtest86+, bad RAM is scary. I had one recently: http://trofi.github.io/posts/209-tracking-down-mysterious-memory-corruption.html
(In reply to Sergei Trofimovich from comment #9) > Maybe try sys-apps/memtest86+, bad RAM is scary. I had one recently: > http://trofi.github.io/posts/209-tracking-down-mysterious-memory-corruption. > html Thx for helping. It had nothing to do with hardware issue, it was rather a vm.overcommit setting. But I still wonder, why >/dev/null 2>&1 is used for compiling gcc.
(In reply to cilly from comment #10) > Thx for helping. It had nothing to do with hardware issue, it was rather a > vm.overcommit setting. What overcommit setting did you use? I'm getting the same out-of-memory errors while trying to emerge gcc-9.3.0
(In reply to Jouni Rinne from comment #11) > (In reply to cilly from comment #10) > > > Thx for helping. It had nothing to do with hardware issue, it was rather a > > vm.overcommit setting. > > What overcommit setting did you use? I'm getting the same out-of-memory > errors while trying to emerge gcc-9.3.0 copied from my sysctl.conf: --- # The Linux kernel supports the following overcommit handling modes # # 0 Heuristic overcommit handling. Obvious overcommits of # address space are refused. Used for a typical system. It # ensures a seriously wild allocation fails while allowing # overcommit to reduce swap usage. root is allowed to # allocate slighly more memory in this mode. This is the # default. # # 1 Always overcommit. Appropriate for some scientific # applications. # # 2 Don't overcommit. The total address space commit # for the system is not permitted to exceed swap + a # configurable percentage (default is 50) of physical RAM. # Depending on the percentage you use, in most situations # this means a process will not be killed while accessing # pages but will receive errors on memory allocation as # appropriate. # # The overcommit policy is set via the sysctl `vm.overcommit_memory'. # The overcommit percentage is set via `vm.overcommit_ratio'. vm.overcommit_memory = 2 vm.overcommit_ratio = 100 # swappiness is a number between 0 and 100, representing how # aggressive the swap policy of the kernel is, or where is the # balance between swapping applications and freeing cache. vm.swappiness = 1 ---
