emerge fails Reproducible: Always
Created attachment 765894 [details] build.log
Your system ran out of resources. Missing emerge --info.
Created attachment 765900 [details] build.log for version 7.2.6.1
Created attachment 765901 [details] emerge --info
(In reply to Erik from comment #4) > Created attachment 765901 [details] > emerge --info When is this from? >KiB Mem: 8152896 total, 706776 free >KiB Swap: 0 total, 0 free That's not much free. Anyway: >/var/tmp/portage/app-office/libreoffice-7.2.6.1/work/libreoffice-7.2.6.1/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx: Assembler messages: >/var/tmp/portage/app-office/libreoffice-7.2.6.1/work/libreoffice-7.2.6.1/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:109: Error: junk `80' after expression This usually means the compiler died. Can you check dmesg too for OOM messages?
Add swap.
Created attachment 765936 [details] emerge --info with swap
Created attachment 765937 [details] build.log for version 7.3.1.1-r1 with swap
(In reply to Erik from comment #8) > Created attachment 765937 [details] > build.log for version 7.3.1.1-r1 with swap - Was there anything in OOM like I mentioned? - >Used CFLAGS: -fno-stack-protector -mstackrealign -march=native -pipe -O2 Please try without -fno-stack-protector and possibly without -mstackrealign. - If you go into /var/tmp/portage/app-office/libreoffice-7.3.1.1-r1/work/libreoffice-7.3.1.1 and run the last command before failure manually, does it work? - You could also try new GCC just stabled. But this is pretty odd and it still seems a lot like OOM although I accept that's odd given the swap and -j1. The compiler shouldn't ever really die like that. The last person who filed a bug similar to this ended up having bad RAM. Can you do a memtest?
(In reply to Sam James from comment #9) > (In reply to Erik from comment #8) > > Created attachment 765937 [details] > > build.log for version 7.3.1.1-r1 with swap > > - Was there anything in OOM like I mentioned? > - >Used CFLAGS: -fno-stack-protector -mstackrealign -march=native -pipe > -O2 > > Please try without -fno-stack-protector and possibly without -mstackrealign. > > - If you go into > /var/tmp/portage/app-office/libreoffice-7.3.1.1-r1/work/libreoffice-7.3.1.1 > and run the last command before failure manually, does it work? > > - You could also try new GCC just stabled. > > But this is pretty odd and it still seems a lot like OOM although I accept > that's odd given the swap and -j1. The compiler shouldn't ever really die > like that. > > The last person who filed a bug similar to this ended up having bad RAM. Can > you do a memtest? basically: nothing about this yet makes sense, and the compiler tends to only die in weird circumstances. It shouldn't crash (ICE) even with bad code, but in your case, it's just.. giving up partway through when calling as(?). That usually happens because some process which got spawned was killed for some reason. Further, usually that reason is OOM. It could be something else - so check dmesg. Other than that, it could be memory corruption, hence suggestion to memtest. But there's no concrete reason that's obvious as to why this would be happening nor is it seemingly generic to LO (it's not something everyone is hitting), so we need to do some work to narrow down what's interesting about your system and rule stuff out. Throwing out e.g. odd flags is part of that.
After disabling all use flags and compiler flags, the package was installed! I will try to add back flags and report which causes the error.
Created attachment 767538 [details] build.log for version 7.2.5.2-r1 with all USE flags disabled and only -mstackrealign in CFLAGS
Executing the last command gives the same error (but with localized error message). It can be executed from anywhere because it includes a cd command: S=/var/tmp/portage/app-office/libreoffice-7.2.5.2-r1/work/libreoffice-7.2.5.2 && I=$S/instdir && W=$S/workdir && mkdir -p $W/CxxObject/bridges/source/cpp_uno/gcc3_linux_x86-64/ $W/Dep/CxxObject/bridges/source/cpp_uno/gcc3_linux_x86-64/ && cd /var/tmp/portage/app-office/libreoffice-7.2.5.2-r1/work/libreoffice-7.2.5.2 && x86_64-pc-linux-gnu-g++ -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DLINUX -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT -DHAVE_POSIX_FALLOCATE -fvisibility=hidden -Wall -Wno-missing-braces -Wnon-virtual-dtor -Wendif-labels -Wextra -Wundef -Wunreachable-code -Wunused-macros -finput-charset=UTF-8 -fmessage-length=0 -fno-common -pipe -fstack-protector-strong -fdiagnostics-color=always -Wdeprecated-copy-dtor -Wduplicated-cond -Wlogical-op -Wshift-overflow=2 -Wunused-const-variable=1 -Wno-cast-function-type -fvisibility-inlines-hidden -fPIC -Wshadow -Woverloaded-virtual -std=c++17 -pthread -mstackrealign -O0 -fstrict-aliasing -fstrict-overflow -fnon-call-exceptions -DEXCEPTIONS_ON -fexceptions -fno-enforce-eh-specs -fno-omit-frame-pointer -fno-strict-aliasing -fno-lto -mno-avx -DLIBO_INTERNAL_ONLY -c $S/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx -o $W/CxxObject/bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.o -I$S/bridges/inc -I$S/include -I$S/config_host -I$W/UnoApiHeadersTarget/udkapi/comprehensive Removing -mstackrealign from that command makes it finish without error.
Can you still reproduce this?
