https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
--- Comment #18 from Дилян Палаузов <dilyan.palauzov at aegee dot org> --- I will sum up the discussion so far on this and other tickets: When one distributes source code software packages, the developers directly or indirectly use AR to create static libraries, when the user wants static libraries. Think on autoconf/libtool packages, where the users of those packages = software developers do not deal with AR. When a mortal user wants to build something with LTO, the user has to pass -flto to the compiler, for any source code package. Doing the LTO build process more complex than that leads to a situation, where LTO is not utilized, due to the complixity of running it. Some distributions install the linker plugin under $libdir/bfd-plugins and make ar/nm/ranlib deal transparently with -flto, but putting the plugin under $libdir/bfd-plugin for using ar/ranlib/nm is apparently kind of secret or too complicated, as not all distributions do this. So sticking to AR for building with LTO is currently not portable. When CMake is used, it chooses the appropriate gcc-ar-4, gcc-ar, llvm-ar-4.0 or llvm-ar (see https://gitlab.kitware.com/cmake/cmake/commit/630235bd9e049a8da47 and https://gitlab.kitware.com/cmake/cmake/commit/75accaae8b6a691b031f2) and ensures, that the just passing -flto will enable LTO. As can be seen from the commits above, instead of installing the linker plugin under $libdir/bfd-plugins, distributions rename gcc-ar to something different. CPython’s autoconf tries to detect if LTO is used and either switches to llvm-lto or (with GCC) uses fat lto objects, but does not use gcc-ar. Likewise valgrind’s ./configure uses gcc-ar, but not llvm-ar, so does libical’s Cmakefile (to enable LTO in old cmake versions). So the solution of compiling platform independent software is not in the distributions, the solution is to do incomplete hacks in the configure steps, and apparently meson has some knowledge how to do this (büt does not append the version number), cmake has the most complete knowledge and experimenting with autoconf nobody provides portable software where LTO is works both under LLVM and GCC. Thus the intention of tweaking ./configure is to achieve portability but nobody managed to achieve it in an optimal way yet. Installing the linker plugin under $libdir/bfd-plugins by the compiler will suggest to all distributions that the linker plugin has to be there and the distributions will ensure that at all time there is a linker plugin, while it is in practice irrelevant from which GCC version the linker plugin comes. It is irrelevant, because the plugin there is only used by ar/nm/ranlib and the differences between the versions of liblto_plugin are insignificant to ar/nm/ranlib. There are now two options: * installing the linker plugin by gcc’s “make install” in $libdir/bfd-plugin which will lead in mid-term to having AR deal with LTO in a portable way * not installing the linker plugin by gcc’s “make install” in $libdir/bfd-plugin. The only portable/cross-platform way to build with LTO is using cmake. Seriously. That said, there are advantages when gcc’s “make install” inserts its plugin in $libdir/bfd-plugins and no disadvantages. While not doing so has only disadvantages. Please explain whe gcc’s “make install” does not insert its linker plugin on the rigth place and how are supposed software developers to write software/build systems, that support LTO on any platform. Finally, not installing the plugin under $libdir/bfd-plugins because of differences in the versions, forces users to use gcc-ar, but it has the very same problems with differences in the versions.
