When running ar on object files built with gcc -flto I get the error message "plugin needed to handle lto object". To fix the issue I need to copy /usr/libexec/gcc/x86_64-redhat-linux/8/liblto_plugin.so.* from /usr/libexec/gcc/x86_64-redhat-linux/8/ into /usr/lib/bfd-plugins/. If the object files have been built with clang -flto I need to copy /usr/lib64/LLVMgold.so into /usr/lib/bfd-plugins/. I guess this bug require collaboration with the gcc and llvm package. But in any case I would expect ar to look for the LTO plugin in /usr/lib64/bfd-plugins/, not in /usr/lib/bfd-plugins/.
Well, for working with gcc LTO objects you should be using gcc-ar, gcc-nm and gcc-ranlib instead of ar, nm and ranlib.
Why? What's the benefit of using the gcc-XXX versions over the binutils ones? (supposing the binutils package looks for the plugins in the correct place)
Those are the wrappers around ar/nm/ranlib that pass --plugin= option to those that are needed to handle this. I think you can't have more than one plugin active, so you can't just try all the possible plugins (note, it isn't just GCC vs. LLVM, each version of those needs a different version of the plugin).
I am not going to pretend I understand the details of all this. But I can confirm after setting this up: $ ls -l /usr/lib/bfd-plugins/ total 0 lrwxrwxrwx. 1 root root 57 Feb 19 17:21 liblto_plugin.so.0 -> /usr/libexec/gcc/x86_64-redhat-linux/8/liblto_plugin.so.0 lrwxrwxrwx. 1 root root 22 Feb 19 17:21 LLVMgold.so -> /usr/lib64/LLVMgold.so Both gcc and clang builds works with -flto, without doing anything else. And according to "man ar": "The GCC plugin is always backwards compatible with earlier versions, so it is sufficient to just copy the newest one." So at least for gcc the different versions shouldn't be an issue. In any case once I have done "CC=gcc-X.Y" I'm fine having to do AR=gcc-ar or whatever. But if the only thing I have done is CFLAGS=-flto I don't expect to have to change anything else.
An strace of ar for a gcc build shows multiple times this: openat(AT_FDCWD, "/usr/bin/../bin/../lib/bfd-plugins", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 10 stat("/usr/bin/../bin/../lib/bfd-plugins/.", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0", {st_mode=S_IFREG|0755, st_size=89280, ...}) = 0 For a clang build openat(AT_FDCWD, "/usr/bin/../bin/../lib/bfd-plugins", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 10 stat("/usr/bin/../bin/../lib/bfd-plugins/.", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0", {st_mode=S_IFREG|0755, st_size=89280, ...}) = 0 stat("/usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so", {st_mode=S_IFREG|0755, st_size=189408, ...}) = 0 And man ar says: "ar iterates over the files in ${libdir}/bfd-plugins in alphabetic order and the first plugin that claims the object in question is used." Not sure if this is what you meant, but it does look like it *can* "just try all the possible plugins". When I did "ln -s /usr/lib64/llvm5.0/lib/LLVMgold.so /usr/lib/bfd-plugins/LLVMgold-5.0.so" I noticed this plugin is accepted for object files built with clang-7. The resulting binaries seem to work fine. But I can't really say if this is luck, or if the LLVMgold plugin is also backwards compatible (or versioned, and it could have rejected LLVMgold-5.0 if a specific object file needed any feature not available in it). In any case I don't expect this to be done, the only two plugins I expect in /usr/lib/bfd-plugins are the ones for the default system versions of gcc and clang.
Related upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24262
Per https://sourceware.org/bugzilla/show_bug.cgi?id=24262#c2 /usr/lib/bfd-plugins/ becomes the official correct location, not /usr/lib64/bfd-plugins/.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I'm trying to install the symlinks in the gcc/llvm packages, but I've hit this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25873
(In reply to Tom Stellard from comment #9) > I'm trying to install the symlinks in the gcc/llvm packages, but I've hit > this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25873 This turned out to be Fedora specific bug #1828587, and has been fixed in binutils-2.34-4.fc33 I've submitted a change to gcc to install liblto_plugin.so in the plugin directory: https://src.fedoraproject.org/rpms/gcc/pull-request/7 Once we agree on this approach, I will commit a similar change to the llvm package.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
It actually works now (even if somehow the plugins are back into /usr/lib64/bfd-plugins instead of /usr/lib/bfd-plugins/ as per https://sourceware.org/bugzilla/show_bug.cgi?id=24262), I was having a different problem.