To avoid dups of bugs like this http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312 where users mistakely call ar/nm/ld without a plugin and gets undefined symbols, it would be great if the utilities was able to recognize objects only with LTO symbols and no other object table and issue warning that compilation is likely going to fail.
Or better still have the utilities load the plugin automatically. I'm using the following patch successfully on my machine: diff --git a/binutils/ar.c b/binutils/ar.c index c424038..4b14dc5 100644 --- a/binutils/ar.c +++ b/binutils/ar.c @@ -138,7 +138,11 @@ static int show_version = 0; static int show_help = 0; +#if BFD_SUPPORTS_PLUGINS +static const char *plugin_target = "plugin"; +#else static const char *plugin_target = NULL; +#endif static const char *target = NULL; @@ -553,7 +557,6 @@ decode_options (int argc, char **argv) break; case OPTION_PLUGIN: #if BFD_SUPPORTS_PLUGINS - plugin_target = "plugin"; bfd_plugin_set_plugin (optarg); #else fprintf (stderr, _("sorry - this program has been built without plugin support\n")); @@ -614,7 +617,6 @@ ranlib_main (int argc, char **argv) /* PR binutils/13493: Support plugins. */ case OPTION_PLUGIN: #if BFD_SUPPORTS_PLUGINS - plugin_target = "plugin"; bfd_plugin_set_plugin (optarg); #else fprintf (stderr, _("sorry - this program has been built without plugin support\n")); diff --git a/binutils/nm.c b/binutils/nm.c index ad38e27..84627bc 100644 --- a/binutils/nm.c +++ b/binutils/nm.c @@ -177,7 +177,11 @@ static char other_format[] = "%02x"; static char desc_format[] = "%04x"; static char *target = NULL; -static char *plugin_target = NULL; +#if BFD_SUPPORTS_PLUGINS +static const char *plugin_target = "plugin"; +#else +static const char *plugin_target = NULL; +#endif /* Used to cache the line numbers for a BFD. */ static bfd *lineno_cache_bfd; @@ -1647,7 +1651,6 @@ main (int argc, char **argv) case OPTION_PLUGIN: /* --plugin */ #if BFD_SUPPORTS_PLUGINS - plugin_target = "plugin"; bfd_plugin_set_plugin (optarg); #else fatal (_("sorry - this program has been built without plugin support\n")); Two small scripts allow me to switch from clang's lto-plugin to gcc's: % cat plugin_clang sudo rm /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/* sudo ln -s /usr/lib64/llvm/LLVMgold.so /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins % cat plugin_gcc sudo rm /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins/* sudo ln -s /usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/liblto_plugin.so.0.0.0 /usr/x86_64-pc-linux-gnu/binutils-bin/lib/bfd-plugins
> Or better still have the utilities load the plugin automatically. Yes, I think ideally the LTO capable compilers should install plugins into the binutils search path and binutils should simply load all available plugins and see what files they claims. That way wrappers won't be needed and mixed LTOs (with LTO objects from different compilers) has chance to work. Honza
Independently on that however I guess binutils should know to warn when the plugin mechanizm fails and LTO only object is being handled the normal way. It is really very common problem to run into and I think it is really hard to diagnoze for everyone except few people familiar with LTO machinery. Honza
Dup *** This bug has been marked as a duplicate of bug 13227 ***