sys-libs/glibc-2.26 and later gcc bootstrap files need updating since gcc-4.7 is not supported anymore...
Here's the content of the current file; this is what we need to reproduce with gcc-6. Sadly README contains no information on how it was generated. huettel@pinacolada ~/tmp/gcc-4.7.3-r1 $ find .|sort . ./README ./amd64 ./amd64/crtbegin.o ./amd64/crtbeginS.o ./amd64/crtbeginT.o ./amd64/crtend.o ./amd64/crtendS.o ./amd64/libgcc.a ./amd64/libgcc_eh.a ./amd64/libgcc_s.so ./amd64/libgcc_s.so.1 ./n32 ./n32/crtbegin.o ./n32/crtbeginS.o ./n32/crtbeginT.o ./n32/crtend.o ./n32/crtendS.o ./n32/libgcc.a ./n32/libgcc_eh.a ./n32/libgcc_s.so ./n32/libgcc_s.so.1 ./n64 ./n64/crtbegin.o ./n64/crtbeginS.o ./n64/crtbeginT.o ./n64/crtend.o ./n64/crtendS.o ./n64/libgcc.a ./n64/libgcc_eh.a ./n64/libgcc_s.so ./n64/libgcc_s.so.1 ./o32 ./o32/crtbegin.o ./o32/crtbeginS.o ./o32/crtbeginT.o ./o32/crtend.o ./o32/crtendS.o ./o32/libgcc.a ./o32/libgcc_eh.a ./o32/libgcc_s.so ./o32/libgcc_s.so.1 ./ppc ./ppc/crtbegin.o ./ppc/crtbeginS.o ./ppc/crtbeginT.o ./ppc/crtend.o ./ppc/crtendS.o ./ppc/libgcc.a ./ppc/libgcc_eh.a ./ppc/libgcc_s.so ./ppc/libgcc_s.so.1 ./ppc64 ./ppc64/crtbegin.o ./ppc64/crtbeginS.o ./ppc64/crtbeginT.o ./ppc64/crtend.o ./ppc64/crtendS.o ./ppc64/libgcc.a ./ppc64/libgcc_eh.a ./ppc64/libgcc_s.so ./ppc64/libgcc_s.so.1 ./s390 ./s390/crtbegin.o ./s390/crtbeginS.o ./s390/crtbeginT.o ./s390/crtend.o ./s390/crtendS.o ./s390/libgcc.a ./s390/libgcc_eh.a ./s390/libgcc_s.so ./s390/libgcc_s.so.1 ./s390x ./s390x/crtbegin.o ./s390x/crtbeginS.o ./s390x/crtbeginT.o ./s390x/crtend.o ./s390x/libgcc.a ./s390x/libgcc_eh.a ./s390x/libgcc_s.so ./s390x/libgcc_s.so.1 ./x32 ./x32/crtbegin.o ./x32/crtbeginS.o ./x32/crtbeginT.o ./x32/crtend.o ./x32/crtendS.o ./x32/libgcc.a ./x32/libgcc_eh.a ./x32/libgcc_s.so ./x32/libgcc_s.so.1 ./x86 ./x86/crtbegin.o ./x86/crtbeginS.o ./x86/crtbeginT.o ./x86/crtend.o ./x86/crtendS.o ./x86/libgcc.a ./x86/libgcc_eh.a ./x86/libgcc_s.so ./x86/libgcc_s.so.1
ftr, in comment #1 that was gcc-4.7.3-r1-multilib-bootstrap.tar.bz2
Those files are verbatim copies of installed gcc crt files and README says so: """It's merely a precompiled version of gcc-4.7.3""". There is many ways you can get those files: - build all interesting targets with crossdev and copy the results: $ equery f gcc | fgrep crtbegin.o | egrep '^/usr/lib/gcc/.*(powerpc64|s390x|x86_64|mips).*7.3.0' /usr/lib/gcc/mips-unknown-linux-gnu/7.3.0/crtbegin.o /usr/lib/gcc/mips64-unknown-linux-gnu/7.3.0/crtbegin.o /usr/lib/gcc/mips64el-unknown-linux-gnu/7.3.0/crtbegin.o /usr/lib/gcc/mipsel-unknown-linux-gnu/7.3.0/crtbegin.o /usr/lib/gcc/powerpc64-unknown-linux-gnu/7.3.0/crtbegin.o /usr/lib/gcc/powerpc64le-unknown-linux-gnu/7.3.0/crtbegin.o /usr/lib/gcc/s390x-unknown-linux-gnu/7.3.0/crtbegin.o /usr/lib/gcc/x86_64-HEAD-linux-gnu/7.3.0/crtbegin.o /usr/lib/gcc/x86_64-UNREG-linux-gnu/7.3.0/crtbegin.o /usr/lib/gcc/x86_64-w64-mingw32/7.3.0/crtbegin.o /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/32/crtbegin.o /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/crtbegin.o - find fresh stage3 and copy files from there Ideally we should stop distributing those files in binary form. I see correct fix for gcc and glibc ebuilds to install headers/crt stubs unconditionally when there is no full multilib support requested. Our current scheme with binaries does not scale well: powerpc64le needs special layout, other libcs might not work, special CFLAGS layouts will likely break, mips little endian is not supported. I think it is this feature request: https://bugs.gentoo.org/614282
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=589ce025faee90c57c76c0da6f8534f707132d8f commit 589ce025faee90c57c76c0da6f8534f707132d8f Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2018-05-01 20:18:52 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2018-05-01 20:19:17 +0000 sys-libs/glibc: Add new bootstrap files from stages, bug 647070 See https://github.com/gentoo/gcc-multilib-bootstrap/ for the source. This is as good as we can do at the moment. Tested by building an x32 glibc on a normal amd64 system. For the glibc-2.26 stabilization we still need new files for PowerPC. Current status: * amd64, x32, x86: Files from gcc-6.4 * s390, s390x: Files from gcc-5.4 (does this work?) * ppc, ppc64: no files, since only gcc-4.9 available * n32, n64, o32: no files, last mips stages are years old, not useful Bug: https://bugs.gentoo.org/647070 Package-Manager: Portage-2.3.31, Repoman-2.3.9 sys-libs/glibc/Manifest | 1 + sys-libs/glibc/glibc-2.26-r7.ebuild | 849 +++++++++++++++++++++ sys-libs/glibc/glibc-2.27-r2.ebuild | 1428 +++++++++++++++++++++++++++++++++++ sys-libs/glibc/glibc-9999.ebuild | 8 +- 4 files changed, 2282 insertions(+), 4 deletions(-)
(In reply to Larry the Git Cow from comment #4) > For the glibc-2.26 stabilization we still need new files for PowerPC. Why it's a stabilization blocker?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=285769c9ff0fcf18d7ea25adac96010b4727a7ab commit 285769c9ff0fcf18d7ea25adac96010b4727a7ab Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2018-05-11 19:54:01 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2018-05-11 19:54:11 +0000 sys-libs/glibc: New tarball with added ppc multilib bootstrap files Bug: https://bugs.gentoo.org/654524 Bug: https://bugs.gentoo.org/647070 Package-Manager: Portage-2.3.36, Repoman-2.3.9 sys-libs/glibc/Manifest | 2 +- sys-libs/glibc/glibc-2.26-r7.ebuild | 2 +- sys-libs/glibc/glibc-2.27-r2.ebuild | 2 +- sys-libs/glibc/glibc-9999.ebuild | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
Only the mips gcc-6 files are still missing.
(In reply to Andreas K. Hüttel from comment #7) > Only the mips gcc-6 files are still missing. OK I see nothing happen there, mips team is defunct.
(In reply to Andreas K. Hüttel from comment #8) > (In reply to Andreas K. Hüttel from comment #7) > > Only the mips gcc-6 files are still missing. > > OK I see nothing happen there, mips team is defunct. What specific files do you need again? I'm currently trying to prepare for new stages right now, but I have one working machine and six different combinations to build, so it takes a month or two. Assuming no surprises. Additionally, I am only building for the old SGI systems, so my ISA choices are mips2 (o32, & uclibc-ng), mips3 (n32), and mips4 (n32, n32_R12K, multilib). All are big-endian. Targets I can't handle are the newer MIPS ISAs, like mips32rX, mips64rX, little-endian, and newer CPU classes. The possible number of permutations for MIPS is dizzying, so I don't think generating these files is really helpful, and it suggests the current process being utilized is not scalable, or practical, to archs like MIPS. Also, I have gcc-7.3.x mostly working fine on my selected build targets, so I am not terribly worried about gcc-6.x anymore. The chroots I am currently updating are all on glibc-2.27 as well, and the one uclibc-ng is on 1.0.30. That all said, if you really need something now for whatever reason, I have a set of stages I completed back in Dec 2016 I can upload and you can pull whatever files you need from those. Those are all gcc-6.x-based. The reason I did not release anything then was building a netboot took longer than thought and I got sidetracked by other priorities and never got back to finishing things.
