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.
signature.asc
Description: OpenPGP digital signature
