https://bugs.kde.org/show_bug.cgi?id=338252

Дилян Палаузов <dilyan.palau...@aegee.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED
     Ever confirmed|0                           |1

--- Comment #22 from Дилян Палаузов <dilyan.palau...@aegee.org> ---
I am against using gcc-ar or gcc-ranlib.  These are probably not available,
when clang is used, and it can do LTO, too.

Instead of cluttering configure.ac to use gcc-ac/gcc-ranlib, it can either rely
on the fact, that /usr/(local/)?/bfd-plugins contain the LTO plugin, or
alternatively compile something with -flto to an object file, call "nm
the-object-file.o" and if the latter prints "missing plugin", then configure
shall tell the user that she has to put the linker plugin under
{libdir}/bfd-plugins .

This would help the user to adjust her system to be able to compile other
software with LTO, even software whose authors don't know about LTO.

LTO is anyway not ready for the prime time yet.  emacs does not lTO-link with
ld.bfd, but with ld.gold and php also doesn't work with lto.  So if the build
process just uses ar/ranlib and it fails, then the user shall try without LTO
or debug, debug, debug...

I would like to know why gcc creates gcc-ar instead of puthing the linker plug
in a place, that normal ar would auto-load it, but I do not expect an answer
here on this.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to