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?
