https://bugs.kde.org/show_bug.cgi?id=338252
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|REOPENED |RESOLVED
--- Comment #24 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
(In reply to Дилян Палаузов from comment #22)
> 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 .
Using directly ar and similar is causing problems on some platforms,
(some of them that I care about). The gcc documentation (including the latest
gcc 7.3) explicitly indicates to use gcc-ar and similar
(I guess this ensures that in case you use a gcc in another path
that the 'standard' /usr/...; that the correct/associated plugins are used.
So, I do not think it is a good idea to diverge (for gcc)
from the explicitly documented way to build a static lib, even
if some advanced users might be able to fix/bypass/... using
plugins in a directory such as /usr/(local/)?/bfd-plugins
(note that on my distro, there is no such directory. So, plugins are
somewhere else, I am guessing properly found by gcc-ar and similar).
>
> 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...
Or rather, configure shall do the correct thing, whenever it can, using
the way as documented in gcc manual.
>
> 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.
As said above, if you have different gcc versions installed, and the plugin
differ according to gcc version, then gcc-ar and similar can
do the job properly. An 'hard-coded' path that ar would use will not
give the same. At least for some gcc, I see the plugin is part of gcc
itself.
As I understand, the real problem with gcc-ar and similar is that this
does not work with llvm, as llvm needs llvm-ar and similar.
I largely prefer to keep this bug closed, and have another one bug
discussing using clang+lto to build valgrind.
I suppose patches for this would not be too difficult, but I am not
an llvm user.
So, can you open another bug related to clang/lto/llvm-ar, ... ?
Thanks
Philippe
--
You are receiving this mail because:
You are watching all bug changes.
