boostrap-prefix.sh fails on stage 3 while building sys-devel/gcc-11.1.0. This is due to code changed in made in GCC-11 branch in commit 432c551b17d655823a4825855b4b966441c8cfb3, and therefore this problem can be avoided by going back to GCC-10. I've worked around this by unmasking the unstable keyword for GCC-11 and therefore was able to complete building the prefix (this includes fix in https://bugs.gentoo.org/788334 to get around issue in stage 1). Reproducible: Always Steps to Reproduce: 1.Follow instruction for creating prefix in https://wiki.gentoo.org/wiki/Project:Prefix/Bootstrap Actual Results: Fails on stage 3 due to sys-devel/gcc-11.1.0 build error. Expected Results: Script should work without failures. Link to the change in question on gcc upstream gitweb: https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/ggc-common.c;h=6f8da300970ebec268fd50abe186091ba5d50273;hp=94da02f11857589d3b731c44c06af766b3d17e95;hb=432c551b17d655823a4825855b4b966441c8cfb3;hpb=11da31998af6d7b7d4d6fcd3f705c17d69baf58b
Created attachment 706380 [details] build.log for sys-deve/gcc-11.1.0
And prefix was being built inside x86-64 ubuntu-20.10
Created attachment 706383 [details] emerge --info in the prefix
sys-devel/gcc-11.1.0 doesn't fail to build when built in the finished prefix with the workarounds.
Created attachment 706401 [details] emerge --info gcc:11
Yeah, just hit this on Ubuntu 20.04 and 20.10 too. Thanks for filing this bug with the details.
I've also hit this on my Gentoo machine as well which is fully built with GCC-11, was trying to build a prefix for my regular user. And as previously stated forcing the stage3 bootstrap to use GCC-10 instead works around the issue, enabling a full GCC-11 rebuild of the prefix afterwards.
hmmm, using gcc-10.3.0 doesn't improve things for me
(In reply to Fabian Groffen from comment #8) > hmmm, using gcc-10.3.0 doesn't improve things for me That's interesting... 10.2.0?
ok, gcc-10.2 same problem, something is hosed (gcc-7 not recent enough?) no idea at this point I have this in stage2 though, so this may be another problem.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=29f4de200d9916a117ec1658c87fad73f3a513e2 commit 29f4de200d9916a117ec1658c87fad73f3a513e2 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2021-06-08 09:12:19 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2021-06-08 09:12:19 +0000 scripts/bootstrap-prefix: fix g++ wrapper In 2dfc27192fbe00e4661ca06a0b18f09a4137dd50 the executable name was fixed, so it wasn't dependant on PATH, however, it broke g++ for that would still call gcc. Fix that now. Mask GCC-11 during stage2 and stage3 for bug #788613. Bug: https://bugs.gentoo.org/788613 Signed-off-by: Fabian Groffen <grobian@gentoo.org> scripts/bootstrap-prefix.sh | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-)
I've was able to build the prefix on Ubuntu 21.04 which has glibc-2.33 (My Gentoo system is glibc.2.32 and Ubuntu-20.10 is 2.32 aswell). According glibc-2.33 release notes mallinfo2 was introduced in this release. The prefix itself uses sys-libs/glibc-2.33 and it correctly shows up in the configuration stage of the build. This should've meant that mallinfo2 is available for gcc-11 during the src_compile stage, but as it isnt id think that maybe the system libc is somehow being used which then doesnt include mallinfo2. The problem with the enviroment then seems to be fixed once the prefix bootstrap script is finished. I started building the prefix before sys-devel/gcc-11 got masked in stage2 and stage3. https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html
Hey thanks for that info, I think it means we'll have to mask gcc-11 on profiles targetting an older libc or something. Yet, it seems like this should be easy enough to fix, so a later version could work again. Anyway, I'm continuing my bootstrap attempts on ubuntu 18 here
I'm in the final stage emerging gcc, so I'm pretty sure this is now worked around sufficiently
