[lto-plugin] : Part 2 for PR lto/47225 - [4.6 regression]: cross-compile fails while configuring libgcc with "xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found"

2011/2/7 Andreas Krebbel <krebbel@linux.vnet.ibm.com>:
>> Hmm, so it adds it to dependency. Feel free to revert the patch, I'll
>> try to rework it. Does it make any difference here, if the initial '-'
>> is put before $(Wl) and the leading minus is removed from Wl
>> definition?
>>
>> I am a bit puzzled as it worked for me.
>
> From a quick look the problem appears to be that your Makefile.am change doesn't only
> affect liblto_plugin_la_LIBADD. It also affects liblto_plugin_la_DEPENDENCIES:
>
> From your patch Makefile.in:
>
>
>  liblto_plugin_la_DEPENDENCIES = $(if $(wildcard \
> -       ../libiberty/pic/libiberty.a),../libiberty/pic/libiberty.a,)
> +       ../libiberty/pic/libiberty.a),$(Wl)../libiberty/pic/libiberty.a,)
>
>
> which is used as rule dependency:
>
> liblto_plugin.la: $(liblto_plugin_la_OBJECTS) $(liblto_plugin_la_DEPENDENCIES)
>        $(liblto_plugin_la_LINK) -rpath $(libexecsubdir) $(liblto_plugin_la_OBJECTS)
> $(liblto_plugin_la_LIBADD) $(LIBS)
>
> -Andreas-
>

Hi Andreas,

the generated dependency is the issue here. Could you test this patch
for s390 (or some other pic target). The following patch bootstraps
successful for x86_64-w64-mingw32, and x86_64-pc-linux-gnu.

Ok for apply?

Thanks in advance,
Kai

* Kai Tietz wrote on Mon, Feb 07, 2011 at 07:32:51PM CET:
> 2011/2/7 Andreas Krebbel <krebbel@linux.vnet.ibm.com>:
> > From a quick look the problem appears to be that your Makefile.am change doesn't only
> > affect liblto_plugin_la_LIBADD. It also affects liblto_plugin_la_DEPENDENCIES:
> >
> > From your patch Makefile.in:
> >
> >
> >  liblto_plugin_la_DEPENDENCIES = $(if $(wildcard \
> > -       ../libiberty/pic/libiberty.a),../libiberty/pic/libiberty.a,)
> > +       ../libiberty/pic/libiberty.a),$(Wl)../libiberty/pic/libiberty.a,)
> >
> >
> > which is used as rule dependency:
> >
> > liblto_plugin.la: $(liblto_plugin_la_OBJECTS) $(liblto_plugin_la_DEPENDENCIES)
> >        $(liblto_plugin_la_LINK) -rpath $(libexecsubdir) $(liblto_plugin_la_OBJECTS)
> > $(liblto_plugin_la_LIBADD) $(LIBS)

> the generated dependency is the issue here. Could you test this patch
> for s390 (or some other pic target). The following patch bootstraps
> successful for x86_64-w64-mingw32, and x86_64-pc-linux-gnu.

Your new patch can possibly cause ordering issues on some platforms
(libiberty is not added at the right order on the link command line).

What you can do however is just overwrite the automatically generated
dependencies, by adding
   liblto_plugin_la_DEPENDENCIES =

automake then should refrain from setting that itself.

I would be fine with such a patch instead, if it works for you.

Thanks for looking into this,
Ralf

* Ralf Wildenhues wrote on Mon, Feb 07, 2011 at 07:43:37PM CET:
> * Kai Tietz wrote on Mon, Feb 07, 2011 at 07:32:51PM CET:
> > 2011/2/7 Andreas Krebbel <krebbel@linux.vnet.ibm.com>:

> > >  liblto_plugin_la_DEPENDENCIES = $(if $(wildcard \
> > > -       ../libiberty/pic/libiberty.a),../libiberty/pic/libiberty.a,)
> > > +       ../libiberty/pic/libiberty.a),$(Wl)../libiberty/pic/libiberty.a,)

> > > which is used as rule dependency:
> > >
> > > liblto_plugin.la: $(liblto_plugin_la_OBJECTS) $(liblto_plugin_la_DEPENDENCIES)
> > >        $(liblto_plugin_la_LINK) -rpath $(libexecsubdir) $(liblto_plugin_la_OBJECTS)
> > > $(liblto_plugin_la_LIBADD) $(LIBS)

> What you can do however is just overwrite the automatically generated
> dependencies, by adding
>    liblto_plugin_la_DEPENDENCIES =

Hmm, I guess it'd be even better if we actually listed the dependencies
here, but without the $(Wc):

  liblto_plugin_la_DEPENDENCIES = $(if $(wildcard \
        ../libiberty/pic/libiberty.a),../libiberty/pic/libiberty.a,)

Sorry for the noise.