> > 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; > }