>
> BFD supports plugin auto-loading for plugins placed in
> /usr/lib/bfd-plugins (if you make it work for GNU LTO objects by
> fixing PR14698). If it does so then we claim LTO IR objects
> via the plugin machinery even if -fno-use-linker-plugin is
> specified (in that case the gcc driver won't pass a -plugin option
> to ld already). Thus the following patch makes the auto-load
> plus -fno-use-linker-plugin combination work by failing at
> plugin-load time if that option is in COLLECT_GCC_OPTIONS.
>
> Built and tested on x86_64-unknown-linux-gnu.
>
> Ok?
>
> (I have to repeat myself that we have too many supported
> LTO-modes-of-operation)
Yep, I definitely do not disagree with this, despite my comments
on =none ;)
>
> Thanks,
> Richard.
>
> 2014-04-01 Richard Biener <rguent...@suse.de>
>
> lto-plugin/
> * lto-plugin.c (onload): Fail to load if -fno-use-linker-plugin
> is set in COLLECT_GCC_OPTIONS.
Yep, this seems make sense and looks like an obvoius patch to me ;)
Honza
>
> Index: lto-plugin/lto-plugin.c
> ===================================================================
> *** lto-plugin/lto-plugin.c (revision 208978)
> --- lto-plugin/lto-plugin.c (working copy)
> *************** onload (struct ld_plugin_tv *tv)
> *** 1067,1071 ****
> --- 1067,1078 ----
> "could not register the all_symbols_read callback");
> }
>
> + /* Support -fno-use-linker-plugin by failing to load the plugin
> + for the case where it is auto-loaded by BFD. */
> + char *collect_gcc_options = getenv ("COLLECT_GCC_OPTIONS");
> + if (collect_gcc_options
> + && strstr (collect_gcc_options, "'-fno-use-linker-plugin'"))
> + return LDPS_ERR;
> +
> return LDPS_OK;
> }
