On Thu, Sep 10, 2020 at 2:26 AM JonY <10wa...@gmail.com> wrote:
>
> On 9/9/20 7:32 AM, JonY wrote:
> > On 9/9/20 7:21 AM, Richard Biener wrote:
> >> On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches
> >> <gcc-patches@gcc.gnu.org> wrote:
> >>>
> >>> Hello,
> >>>
> >>> The lto plugis are tied to the built GCC anyway, so there isn't much
> >>> point to versioning them.
> >>
> >> In fact the lto plugins are not tied to the built GCCs very much, instead
> >> we try to ensure compatibility so that a single plugin can be used with
> >> multiple GCC versions.
> >>
> >
> > I see, I was not aware of this.
> >
> >>> * gcc/config.host: Remove version string
> >>> * lto-plugin/Makefile.am: Use libtool -avoid-version
> >>> * lto-plugin/Makefile.in: Regenerate
> >>>
> >>> This patch has been in use with Cygwin gcc for a long time and should be
> >>> pushed upstream. Patch OK?
> >>
> >> The libtool docs are not very specific here but does this affect the
> >> result for Linux ELF platforms at all?
> >
> > With current builds:
> >
> > /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.la
> > /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so
> > /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0
> > /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0.0.0
> >
> > With -avoid-version it will only generate liblto_plugin.so, from
> > gcc/config.host, it is already what is loaded.
> >
> > I will do a native linux build to confirm this.
> >
>
> I did a bootstrap build of gcc on Linux and it produced the following
> after installing:
>
> libexec/gcc/x86_64-pc-linux-gnu/11.0.0/liblto_plugin.la
> libexec/gcc/x86_64-pc-linux-gnu/11.0.0/liblto_plugin.so
>
> I tested with the following command:
>
> echo 'main(){}' | strace -f -o gcc.log -- ./inst/bin/gcc -xc - -v
> -fuse-linker-plugin -o aa.out
>
> I can confirm liblto is still loaded correctly from the logs, likewise
> renaming it away will cause an error.
>
> Seems to be fine on Linux.OK then. Thanks, Richard.
