Re: Fix bootstrap with --disable-shared and linker plugin

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> This kind of subverts the intention of --disable-shared disabling shared
> library generation.  But there is precedent with libiberty; and one can
> argue both to be internal libraries.  I assume there are other mechanisms
> in place actually disabling lto-plugin on systems where shared libraries
> are not supported at all?

There is no point building plugin on hosts that do not support shared libraries
since the plugin can not be plugged into linker. 
In these cases we must arrange toplevel configury to not build the plugin at all
or we confuse the detection in GCC configure whether it should or should not
enable -fuse-linker-plugin by default.  That one is based on presence of lto-plugin
Makefile and support for --plugin in the linker command line.
(probably on hosts that do not support dynamic libraries the linker will not be configured
with plugin support, but for in-tree binutils we skip this test and do it solely on
presence of gold or resonably recent GNU LD).

Toplevel configure already contains tests whether the plugin makes sense for
host (enabling it for ELF and cygwin targets only) Is there easy test to see if
shared libs can be built we can put into toplevel configure?
> 
> Other than that, the patch seems OK to me.  Bugzilla seems down at the
> moment so I cannot compare with the bug description.

I will commit the updated patch simply adding --enable-shared to lto-plugin
configury as suggested by paolo once I finish the testing.
This will get us to better shape solving the bootstrap problems reported.

Honza
> 
> Thanks,
> Ralf
> 
> > 	PR lto/47225
> > 	* Makefile.def (lto-plugin module): Add @extra_host_lto_plugin_configure_flags.
> > 	* configure.ac: Set extra_host_lto_plugin_configure_flags=--enable-shared
> > 	when doing plugin.
> > 	* Makefile.in: Regenerate.
> > 	* configure: Regenerate.