https://bugs.kde.org/show_bug.cgi?id=338252
--- Comment #26 from Дилян Палаузов <dilyan.palau...@aegee.org> --- With python 3.6, doing "./configure --with-lto --enable-optimizations && make" compiles with -flto, but calls ranlib/ar, not gcc-ranlib or gcc-ar. Why can python-lto live without gcc-ranlib, but valgrind cannot? Also "./configure --with-lto" alone does not imply -flto. > > Concerning installing by default the plugins on the compiler's "make > > install" on the location where binutils will look for them I filled > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934 and > > https://bugs.llvm.org/show_bug.cgi?id=36802. > Which, as I understand, does not work if you have several gcc versions > installed. It works, as the plugin is backwards compatible. You just install the newest gcc-plugin, it then handles the older versions. In particular, if x86_64-pc-linux-gnu-gcc-6.4.1 is installed on a system before x86_64-pc-linux-gnu-gcc-6.4.1 is installed, and a file is then compiled with 6.4.1, strace shows that gcc-ar calls 7.3.1/liblto_plugin.so . Concerning how LTO-libraries shall be built in portable way - by detecting in ./configure whether gcc or clang is used and then switching to gcc-ranlib or llvm-ranlib and why gcc does recomment gcc-nm instead of installing the plugin at the right place I asked at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 and http://lists.llvm.org/pipermail/llvm-dev/2018-March/122018.html . While both llvm and gcc can do LTO, but considering that after being asked neither on clang side is described how to build the LTO plugin (https://bugs.llvm.org/show_bug.cgi?id=32759#c3) nor on gcc side the plugin is installed on the right place (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345), honestly, I don't think that any of the llvm and gcc teams is willing to put efforts to offer LTO for the masses. For switching the __asm__ in coregrind/m_(main,libcsetjmp).c I opened https://bugs.kde.org/show_bug.cgi?id=392180 . > * allow to configure valgrind using CFLAGS (a.o. to support LTO) How shall this work? I can imagine at first place substituting -S with -E in Makefile.vex.am-92- $(CC) $(CFLAGS_FOR_GENOFFSETS) \ Makefile.vex.am-93- $(LIBVEX_CFLAGS_NO_LTO) \ Makefile.vex.am-94- $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@) \ Makefile.vex.am:95: -O -S -o auxprogs/genoffsets.s \ Makefile.vex.am-96- $(srcdir)/auxprogs/genoffsets.c Makefile.vex.am-97- grep xyzzy auxprogs/genoffsets.s | grep "^[# ]*#define" \ Makefile.vex.am-98- | sed "s/# #define/#define/g" \ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934#c1 suggests that distributions are supposed to install the LTO-plugin on the right place. Do the distrubutuions you care about do so and if not, why? -- You are receiving this mail because: You are watching all bug changes.
