[Bug lto/84934] New: Installing the lto plugin where binutils will look for it

[dilyan.palauzov at aegee dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934

            Bug ID: 84934
           Summary: Installing the lto plugin where binutils will look for
                    it
           Product: gcc
           Version: 8.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dilyan.palauzov at aegee dot org
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

For the LTO prime time to arise, "gcc/Makefile install" shall put the
liblto_plugin in a place, where the ar/ranlib/nm tools load it.  They load
search for plugins in the {libdir}/bfd-plugins directory.

Currently users detect in autoconf if they will do LTO, then switch
ar/nm/ranlib to gcc-ar/gcc-nm/gcc-ranlib in order to avoid dealing with the
--plugin and because they are unaware of the bfd-plugin directory.  This is
unacceptable.

There are several options:
*) ar/nm/ranlib provide a mechanism to show the directory, where they look for
plugins, and gcc installs the plugins there,
*) ar/nm/ranlib ask gcc, clang and the other compilers where they have put
their plugins.
*) gcc and binutils mutually agree on a directory where the plugins are
installed and install/read the plugins there.  Assuming that both gcc and
binutils share the same value for {libdir}, being it /usr/local/lib, or
/usr/lib64, gcc could install it in {libdir}/bfd-plugins, clang can do the same
for LLVMgold.so , and then binutils don't change, as they look for the files
there.

What speaks against the third option?