Bug 728638 – sys-devel/gcc[lto] fails src_compile with binutils-config[-native-symlinks] ( /work/build/./prev-gcc/gcc-ar: Cannot find binary 'ar' )

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Kent Fredric (IRC: kent\n) (RETIRED) 2020-06-18 09:55:19 UTC]

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: [e-mail]
 * 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

[Comment 1 Sergei Trofimovich (RETIRED) 2020-06-20 21:28:30 UTC]

It's specific to gcc-ar wrapper.

[Comment 2 Sergei Trofimovich (RETIRED) 2020-06-21 09:31:27 UTC]

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.

[Comment 3 Sergei Trofimovich (RETIRED) 2020-06-21 11:40:51 UTC]

(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

[Comment 4 Kent Fredric (IRC: kent\n) (RETIRED) 2020-09-22 20:39:15 UTC]

(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.

[Comment 5 Sergei Trofimovich (RETIRED) 2020-09-25 07:42:54 UTC]

(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>.

[Comment 6 Kent Fredric (IRC: kent\n) (RETIRED) 2020-09-25 09:10:59 UTC]

(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.

[Comment 7 Sergei Trofimovich (RETIRED) 2020-09-27 18:14:28 UTC]

(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.