emerge fails with (just the abbreviated first few lines of actual errors .../work/libreoffice-6.4.7.2/include/o3tl/lru_map.hxx:51:11: error: 'size_t' does not name a type 51 | const size_t mMaxSize; | ^~~~~~ .../work/libreoffice-6.4.7.2/include/o3tl/lru_map.hxx:17:1: note: 'size_t' is defined in header '<cstddef>'; did you forget to '#include <cstddef>'? Reproducible: Always Expected Results: Adding "#include <cstddef>" to that file seems to fix all the errors in build.log (I'll try to attach if it's not too large) but it may take some hours for the emerge to actually finish. I'll reconfirm once it finishes or fails further.
Please don't waste your time with GCC-11 on stable packages. At this stage bugs are relevant for me if they are reproduced in ~arch.
Understood. However, in this case, for me to try libreoffice 7.1.2.2 requires adding a bunch of other ~ packages, and it is not clear that it will even be possible with icedtea-bin-3.16. That means I can't install the stable libreoffice (unless my personal patch works) and I can't install the unstable libreoffice without unmasking lots of other packages, if it will work at all with icedtea. (I'll see if I can do it with -java, since I don't currently use base, but unfortunately, I won't personally have time to try that until I'm back from vacation. I'm not sure if that means closing this (wontfix?) or leaving it as a reminder for confirmation with 7.1 (which I suspect might actually be ok here, per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984204.
(In reply to Jack from comment #2) > Understood. However, in this case, for me to try libreoffice 7.1.2.2 > requires adding a bunch of other ~ packages, and it is not clear that it > will even be possible with icedtea-bin-3.16. That means I can't install the > stable libreoffice (unless my personal patch works) and I can't install the > unstable libreoffice without unmasking lots of other packages, if it will > work at all with icedtea. (I'll see if I can do it with -java, since I > don't currently use base, but unfortunately, I won't personally have time to > try that until I'm back from vacation. > > I'm not sure if that means closing this (wontfix?) or leaving it as a > reminder for confirmation with 7.1 (which I suspect might actually be ok > here, per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984204. I'd consider using stable GCC for now as a compromise (or as you say, turning off Java).
True - I was just testing a full emerge @world with gcc11, so it's truly not critical for me. The previously installed libreoffice (as well as the large handful of others that failed) continues to work. For those I have not already reported, I'll only report if testing versions also fail.
(In reply to Jack from comment #4) > True - I was just testing a full emerge @world with gcc11, so it's truly not > critical for me. The previously installed libreoffice (as well as the large > handful of others that failed) continues to work. For those I have not > already reported, I'll only report if testing versions also fail. Personally, I keep the stable gcc around too (add both sys-devel/gcc:10 and sys-devel/gcc:11 to your world file).
Yes, that's what I've already done. As I said, I'm OK with closing this if the intent is to not fix 6.4 for gcc11, expecting 7.1 to be stable relatively soon. (Also hoping that 7.1 will eventually work with icedtea.)
(In reply to Jack from comment #6) > (Also hoping that 7.1 will eventually work with icedtea.) That unfortunately depends entirely on the right version of icedtea to appear in Portage.
For anyone searching about this, I can confirm the simple, one line addition from the initial post allows successful completion of the emerge. I haven't tested exhaustively, but localc runs on successfully opens several of my spreadsheets.
Closing this bug since 7.1.3.2 was unmasked in commit 39f0ab3ba085648310449bdb6cf8ae9c9ffbef3a.
Thanks. I won't be able to test until I'm home in about two more weeks.
