Created attachment 645152 [details] gcc-10.1.0-r1:20200617-093925.log.gz This failure happens on all slots of GCC I've tested in tree. * Package: sys-devel/gcc-10.1.0-r1 * Repository: gentoo * Maintainer: toolchain@gentoo.org * USE: abi_x86_64 amd64 cxx d doc elibc_glibc fortran go graphite kernel_linux lto multilib nls nptl objc objc++ objc-gc openmp pch pie sanitize ssp userland_GNU vtv * FEATURES: ccache compressdebug network-sandbox preserve-libs sandbox splitdebug userpriv usersandbox /var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./prev-gcc/gcc-ar -B/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./prev-gcc/ rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./d-demangle.o ./dwarfnames.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filedescriptor.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./vprintf-support.o ./rust-demangle.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./simple-object-xcoff.o ./sort.o ./spaces.o ./splay-tree.o ./stack-limit.o ./strerror.o ./strsignal.o ./timeval-utils.o ./unlink-if-ordinary.o ./xasprintf.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./xvasprintf.o ./setproctitle.o /var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./prev-gcc/gcc-ar: Cannot find binary 'ar' make[3]: *** [Makefile:252: libiberty.a] Error 1 make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/libiberty' make[2]: *** [Makefile:11317: all-stage2-libiberty] Error 2 make[2]: Leaving directory '/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build' make[1]: *** [Makefile:25752: stage2-bubble] Error 2 make[1]: Leaving directory '/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build' make: *** [Makefile:25967: bootstrap-lean] Error 2 * ERROR: sys-devel/gcc-10.1.0-r1::gentoo failed (compile phase): * emake failed
It's specific to gcc-ar wrapper.
Created attachment 645494 [details, diff] gcc-10.1.0-default-target.patch Try gcc-10.1.0-default-target.patch. I'm interested in both gcc bootstrap success and ${CHOST}-gcc-ar functioning after gcc is installed.
(In reply to Sergei Trofimovich from comment #2) > Created attachment 645494 [details, diff] [details, diff] > gcc-10.1.0-default-target.patch > > Try gcc-10.1.0-default-target.patch. I'm interested in both gcc bootstrap > success and ${CHOST}-gcc-ar functioning after gcc is installed. Actually, that breaks stage2/3 comparison after bootstrap. Probably because ${CHOST}-ar used host's lto plugin instead of locally built one. We'll need an ar tool redirector in gcc similar to existing ld/nm/as redirectors: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/exec-tool.in;h=4553084829697a028c9ce4b210151ddc958d3013;hb=HEAD
(In reply to Sergei Trofimovich from comment #3) > (In reply to Sergei Trofimovich from comment #2) > > Created attachment 645494 [details, diff] [details, diff] [details, diff] > > gcc-10.1.0-default-target.patch > > > > Try gcc-10.1.0-default-target.patch. I'm interested in both gcc bootstrap > > success and ${CHOST}-gcc-ar functioning after gcc is installed. > > Actually, that breaks stage2/3 comparison after bootstrap. Probably because > ${CHOST}-ar used host's lto plugin instead of locally built one. We'll need > an ar tool redirector in gcc similar to existing ld/nm/as redirectors: > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/exec-tool.in; > h=4553084829697a028c9ce4b210151ddc958d3013;hb=HEAD > sys-devel/gcc[lto] Build using Link Time Optimizations (LTO) Does USE=lto *just* make sure gcc itself is lto'd, or does it do more than that? I assume the former, but I just want to be sure.
(In reply to Kent Fredric (IRC: kent\n) from comment #4) > (In reply to Sergei Trofimovich from comment #3) > > (In reply to Sergei Trofimovich from comment #2) > > > Created attachment 645494 [details, diff] [details, diff] [details, diff] [details, diff] > > > gcc-10.1.0-default-target.patch > > > > > > Try gcc-10.1.0-default-target.patch. I'm interested in both gcc bootstrap > > > success and ${CHOST}-gcc-ar functioning after gcc is installed. > > > > Actually, that breaks stage2/3 comparison after bootstrap. Probably because > > ${CHOST}-ar used host's lto plugin instead of locally built one. We'll need > > an ar tool redirector in gcc similar to existing ld/nm/as redirectors: > > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/exec-tool.in; > > h=4553084829697a028c9ce4b210151ddc958d3013;hb=HEAD > > > sys-devel/gcc[lto] Build using Link Time Optimizations (LTO) > > Does USE=lto *just* make sure gcc itself is lto'd, or does it do more than > that? > > I assume the former, but I just want to be sure. Depends on what you are looking for. metadata.xml says: <flag name="lto">Build using Link Time Optimizations (LTO)</flag>.
(In reply to Sergei Trofimovich from comment #5) > (In reply to Kent Fredric (IRC: kent\n) from comment #4) > > (In reply to Sergei Trofimovich from comment #3) > > > (In reply to Sergei Trofimovich from comment #2) > > > > Created attachment 645494 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > gcc-10.1.0-default-target.patch > > > > > > > > Try gcc-10.1.0-default-target.patch. I'm interested in both gcc bootstrap > > > > success and ${CHOST}-gcc-ar functioning after gcc is installed. > > > > > > Actually, that breaks stage2/3 comparison after bootstrap. Probably because > > > ${CHOST}-ar used host's lto plugin instead of locally built one. We'll need > > > an ar tool redirector in gcc similar to existing ld/nm/as redirectors: > > > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/exec-tool.in; > > > h=4553084829697a028c9ce4b210151ddc958d3013;hb=HEAD > > > > > sys-devel/gcc[lto] Build using Link Time Optimizations (LTO) > > > > Does USE=lto *just* make sure gcc itself is lto'd, or does it do more than > > that? > > > > I assume the former, but I just want to be sure. > > Depends on what you are looking for. metadata.xml says: <flag > name="lto">Build using Link Time Optimizations (LTO)</flag>. And I just quoted that. The problem is for me it is insufficiently clear. I can't tell if this: - Changes the build of GCC itself to ensure GCC is linked with -flto - Changes the build of GCC so that all binaries compiled with GCC are effectively compiled with -flto Compare with say: - ssp - pie - pch - vtv - nptl These all affect *how* gcc compiles things, not just how gcc is compiled.
(In reply to Kent Fredric (IRC: kent\n) from comment #6) > (In reply to Sergei Trofimovich from comment #5) > > (In reply to Kent Fredric (IRC: kent\n) from comment #4) > > > (In reply to Sergei Trofimovich from comment #3) > > > > (In reply to Sergei Trofimovich from comment #2) > > > > > Created attachment 645494 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > > gcc-10.1.0-default-target.patch > > > > > > > > > > Try gcc-10.1.0-default-target.patch. I'm interested in both gcc bootstrap > > > > > success and ${CHOST}-gcc-ar functioning after gcc is installed. > > > > > > > > Actually, that breaks stage2/3 comparison after bootstrap. Probably because > > > > ${CHOST}-ar used host's lto plugin instead of locally built one. We'll need > > > > an ar tool redirector in gcc similar to existing ld/nm/as redirectors: > > > > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/exec-tool.in; > > > > h=4553084829697a028c9ce4b210151ddc958d3013;hb=HEAD > > > > > > > sys-devel/gcc[lto] Build using Link Time Optimizations (LTO) > > > > > > Does USE=lto *just* make sure gcc itself is lto'd, or does it do more than > > > that? > > > > > > I assume the former, but I just want to be sure. > > > > Depends on what you are looking for. metadata.xml says: <flag > > name="lto">Build using Link Time Optimizations (LTO)</flag>. > > And I just quoted that. The problem is for me it is insufficiently clear. > > I can't tell if this: > > - Changes the build of GCC itself to ensure GCC is linked with -flto > - Changes the build of GCC so that all binaries compiled with GCC are > effectively compiled with -flto In gentoo gcc always enables LTO frontend. USE=lto builds gcc itself with LTO.
