Created attachment 382542 [details] emerge --info '=app-office/libreoffice-4.2.5.2' Hello, When trying to compile app-office/libreoffice-4.2.5.2 on x32 system, the compile phase will fail during compilation (unfortunately, always after 4 hours). As requested, here some informations: GENTOO_VM= CLASSPATH="" JAVA_HOME="/etc/java-config-2/current-system-vm" JAVACFLAGS="" COMPILER="" As attachment, you may found the "emerge --info", the config.log and the build.log (gziped).
Created attachment 382544 [details] config.log
Created attachment 382546 [details] app-office:libreoffice-4.2.5.2:20140808-130620.log.gz Around line 32342, we can see: /bin/sh: line 1: 2374 Segmentation fault I will provide more informations, if I find some about it.
Looks like you ran out of memory. You have ~8GB RAM and 9 make jobs.
I am sure it's not a problem of memory, I compiled on my disk, as we can see the path /var/tmp/portage-ondisk/portage/... Please reconsidere.
(In reply to Thibaud "thican" CANALE from comment #4) > I am sure it's not a problem of memory, I compiled on my disk, as we can see > the path /var/tmp/portage-ondisk/portage/... I wasn't talking about storage. I was talking about having nine make jobs and eight gigabytes to share between them. That's less than a gigabyte per job and *FLAGS=-pipe makes the compiler use even more RAM (instead of more storage).
(In reply to Jeroen Roovers from comment #5) > (In reply to Thibaud "thican" CANALE from comment #4) >> I am sure it's not a problem of memory, I compiled on my disk, as we can see >> the path /var/tmp/portage-ondisk/portage/... > > I wasn't talking about storage. Me neither. > I was talking about having nine make jobs > and eight gigabytes to share between them. That's less than a gigabyte per > job and *FLAGS=-pipe makes the compiler use even more RAM (instead of more > storage). I have swap too, 8GB of RAM + 8GB of swap. I know the informations about the "-pipe" flag. Does a lack of memory create a segmentation fault? I saw process got killed, but not a "segfault". When you talk about "nine make jobs", are you talking about my MAKEOPTS flags (set on "-j9 -l4") or about this error message? "make[1]: INTERNAL: Exiting with 10 jobserver tokens available; should be 9!" And I am sure it's not about RAM, because I succeeded to compile libreoffice on a computer with only 2 GB of RAM, 2-3 years ago (yes, with -pipe like always). May we talk about the bug please? I don't understand the log, and I am searching to reexecute the command line.
Virtual memory doesn't count here, only real memory. Blame GCC for giving you segmentation faults there. You have 9 make jobs and 8 gigabytes of RAM, so if a few of those jobs manage to use a couple of gigabytes each, you run out of memory, swap or no swap. You can fix this by running fewer jobs and/or by using more temporary storage (i.e. remove -pipe from your *FLAGS). Now either you investigate this properly or you come back with a proper gdb backtrace and at best a patch for the issue. Before that, there is nothing we can do here.
Created attachment 382622 [details] app-office:libreoffice-4.2.5.2:20140810-015132.log.gz Hello, again. (In reply to Jeroen Roovers from comment #7) > Now either you investigate this properly or you come back with a proper gdb > backtrace and at best a patch for the issue. Before that, there is nothing > we can do here. That's why I said ... (In reply to Thibaud "thican" CANALE from comment #2) > I will provide more informations, if I find some about it. ... because I have not idea where to find, otherwise, I would have already give a backtrace. So, as requested (I waited the night to do this long task), I changed CFLAGS, CXXFLAGS and MAKEOPTS. As you can see in the new build.log named app-office:libreoffice-4.2.5.2:20140810-015132.log.gz, line 81, we have: checking for explicit CFLAGS... -march=corei7-avx -O2 and line 533, there is: /usr/bin/make -j 4 -j4 -f /var/tmp/portage-ondisk/portage/app-office/libreoffice-4.2.5.2/work/libreoffice-4.2.5.2/Makefile.gbuild \ There, I reduced the number of jobs, and I disabled "pipe" and "ggdb" options. But still, there is a segmentation fault. I can't help you if you can't help me, and I don't want to waste more of my time by doing some work on a report closed just because ... I can't help you. I am doing my best, maybe it's easy for you, but not for me.
I see nothing has changed here… I give up on you. As I said “I am doing my best, maybe it's easy for you, but not for me”, and I didn't ignore the advice you gave, this one : “i.e. remove -pipe from your *FLAGS”. Still the same error. But no, nothing new there. Like, the goal is to reach the "RESOLVED" status the faster, even if it is not "FIXED" after (I say that because unfortunately, your are not the only one to play this game). On my "normal" system, I used to install the binary ones, but on x32, there was not such binary for this platform. I won't play the game to change the status on this bug, but I know I don't have to expect a good support anymore with this attitude. I wish I didn't spend my time trying something new and spending more time to do reports about it.
