https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Дилян Палаузов from comment #13)
> At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345#c4 is written that
> “Right now the plugin from any gcc can be used with any gcc.” This is not
> the same as the last comment. Please clarify again, if any gcc plugin can
> be used with any gcc.
Well, liblto_plugin.so is only half of the story. Yes, using any version
will probably "work" but you might get better experience with using a newer
version (though that newer version might present older GCC with resolution
files they do not understand).
> If several plugins can be installed simultaneously and the first one that
> claims the .o file wins, why aren’t plugins for both GCC7 and GCC8 installed
> at the same time? Just for gcc8 files, the gcc7 plugin will not claim the
> responsibility.
It doesn't work that way since any liblto_plugin.so version will accept
any GCC LTO files. It is the lto-wrapper binary that is found to the
one matching the GCC driver version used to invocate the link that
ultimately determines your luck - here strict version matching is required.
Thus LTO linking objects from mixed GCC version is doomed to fail
fatally.
Note plugin auto-loading will only work reliably for ar/nm/ranlib because
of this and indeed for those the version of the plugin doesn't really matter.
