| Message ID | 82361830-475f-85ab-11bb-c4d8a595754b@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | Cygwin/MinGW: Do not version lto plugins | expand |
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. > * 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? Richard. >
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.
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.
On Thu, Sep 10, 2020 at 2:26 AM JonY <10walls@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.
On 9/10/20 9:44 AM, Richard Biener wrote: >> >> 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. > Thanks for reviewing, pushed to master branch ae6cf62861b5e9acb518b016ddbe7f783206f65f.
On 9/10/20 1:57 PM, JonY via Gcc-patches wrote: > On 9/10/20 9:44 AM, Richard Biener wrote: >>> >>> 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. >> > > Thanks for reviewing, pushed to master branch > ae6cf62861b5e9acb518b016ddbe7f783206f65f. > Hello. I see the patch broke auto-loading support in bintuils which automatically try to load plugins in bfd-plugins folder: One example: [ 108s] ar cr libbuiltins.a builtins.o alias.o bind.o break.o builtin.o caller.o cd.o colon.o command.o common.o declare.o echo.o enable.o eval.o evalfile.o evalstring.o exec.o exit.o fc.o fg_bg.o hash.o help.o history.o jobs.o kill.o let.o mapfile.o pushd.o read.o return.o set.o setattr.o shift.o source.o suspend.o test.o times.o trap.o type.o ulimit.o umask.o wait.o getopts.o shopt.o printf.o getopt.o bashgetopt.o complete.o [ 108s] ar: builtins.o: plugin needed to handle lto object Thanks, Martin
On Mon, Sep 21, 2020 at 1:33 PM Martin Liška <mliska@suse.cz> wrote: > > On 9/10/20 1:57 PM, JonY via Gcc-patches wrote: > > On 9/10/20 9:44 AM, Richard Biener wrote: > >>> > >>> 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. > >> > > > > Thanks for reviewing, pushed to master branch > > ae6cf62861b5e9acb518b016ddbe7f783206f65f. > > > > Hello. > > I see the patch broke auto-loading support in bintuils which > automatically try to load plugins in bfd-plugins folder: > > One example: > [ 108s] ar cr libbuiltins.a builtins.o alias.o bind.o break.o builtin.o caller.o cd.o colon.o command.o common.o declare.o echo.o enable.o eval.o evalfile.o evalstring.o exec.o exit.o fc.o fg_bg.o hash.o help.o history.o jobs.o kill.o let.o mapfile.o pushd.o read.o return.o set.o setattr.o shift.o source.o suspend.o test.o times.o trap.o type.o ulimit.o umask.o wait.o getopts.o shopt.o printf.o getopt.o bashgetopt.o complete.o > [ 108s] ar: builtins.o: plugin needed to handle lto object Isn't that eventually just because the 'gcc' package looks for liblto_plugin.so.0.0.0 instead of liblto_plugin.so? Richard. > Thanks, > Martin
On 9/21/20 1:33 PM, Martin Liška wrote: > On 9/10/20 1:57 PM, JonY via Gcc-patches wrote: >> On 9/10/20 9:44 AM, Richard Biener wrote: >>>> >>>> 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. >>> >> >> Thanks for reviewing, pushed to master branch >> ae6cf62861b5e9acb518b016ddbe7f783206f65f. >> > > Hello. > > I see the patch broke auto-loading support in bintuils which > automatically try to load plugins in bfd-plugins folder: > > One example: > [ 108s] ar cr libbuiltins.a builtins.o alias.o bind.o break.o builtin.o caller.o cd.o colon.o command.o common.o declare.o echo.o enable.o eval.o evalfile.o evalstring.o exec.o exit.o fc.o fg_bg.o hash.o help.o history.o jobs.o kill.o let.o mapfile.o pushd.o read.o return.o set.o setattr.o shift.o source.o suspend.o test.o times.o trap.o type.o ulimit.o umask.o wait.o getopts.o shopt.o printf.o getopt.o bashgetopt.o complete.o > [ 108s] ar: builtins.o: plugin needed to handle lto object Sorry, it's not caused by your patch. It's our SUSE-specific package setup. Thanks, Martin > > Thanks, > Martin
On 9/21/20 1:37 PM, Richard Biener wrote: > Isn't that eventually just because the 'gcc' package looks for > liblto_plugin.so.0.0.0 instead of liblto_plugin.so? Yes. Martin
On 9/21/20 11:38 AM, Martin Liška wrote: > Sorry, it's not caused by your patch. It's our SUSE-specific package setup. > How does liblto_plugin.so.0.0.0 get loaded? I find only mentions of liblto_plugin.so. Is Suse GCC patched to use the versioned library?
On 9/21/20 3:09 PM, JonY wrote: > On 9/21/20 11:38 AM, Martin Liška wrote: >> Sorry, it's not caused by your patch. It's our SUSE-specific package setup. >> > > How does liblto_plugin.so.0.0.0 get loaded? I find only mentions of > liblto_plugin.so. We make a symlink to bfd-plugins folder. > > Is Suse GCC patched to use the versioned library? > No, but we create the aforementioned symlink. Martin
diff --git a/gcc/config.host b/gcc/config.host index 84f0433e2ad..373d5efd8da 100644 --- a/gcc/config.host +++ b/gcc/config.host @@ -232,7 +232,7 @@ case ${host} in out_host_hook_obj=host-cygwin.o host_xmake_file="${host_xmake_file} i386/x-cygwin" host_exeext=.exe - host_lto_plugin_soname=cyglto_plugin-0.dll + host_lto_plugin_soname=cyglto_plugin.dll ;; i[34567]86-*-mingw32*) host_xm_file=i386/xm-mingw32.h @@ -240,7 +240,7 @@ case ${host} in host_exeext=.exe out_host_hook_obj=host-mingw32.o host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o" - host_lto_plugin_soname=liblto_plugin-0.dll + host_lto_plugin_soname=liblto_plugin.dll ;; x86_64-*-mingw*) use_long_long_for_widest_fast_int=yes @@ -249,7 +249,7 @@ case ${host} in host_exeext=.exe out_host_hook_obj=host-mingw32.o host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o" - host_lto_plugin_soname=liblto_plugin-0.dll + host_lto_plugin_soname=liblto_plugin.dll ;; i[34567]86-*-darwin* | x86_64-*-darwin*) out_host_hook_obj="${out_host_hook_obj} host-i386-darwin.o" diff --git a/lto-plugin/Makefile.am b/lto-plugin/Makefile.am index ba5882df7a7..204b25f45ef 100644 --- a/lto-plugin/Makefile.am +++ b/lto-plugin/Makefile.am @@ -21,7 +21,7 @@ in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES), $(gcc_build_dir)/$(lib)) liblto_plugin_la_SOURCES = lto-plugin.c # Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS. liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) \ - $(lt_host_flags) -module -bindir $(libexecsubdir) + $(lt_host_flags) -module -avoid-version -bindir $(libexecsubdir) # Can be simplified when libiberty becomes a normal convenience library. libiberty = $(with_libiberty)/libiberty.a libiberty_noasan = $(with_libiberty)/noasan/libiberty.a diff --git a/lto-plugin/Makefile.in b/lto-plugin/Makefile.in index 7da7cd26dbf..834699b439e 100644 --- a/lto-plugin/Makefile.in +++ b/lto-plugin/Makefile.in @@ -350,7 +350,7 @@ libexecsub_LTLIBRARIES = liblto_plugin.la in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES), $(gcc_build_dir)/$(lib)) liblto_plugin_la_SOURCES = lto-plugin.c # Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS. -liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) $(lt_host_flags) -module \ +liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) $(lt_host_flags) -module -avoid-version \ -bindir $(libexecsubdir) $(if $(wildcard \ $(libiberty_noasan)),, $(if $(wildcard \ $(libiberty_pic)),,-Wc,$(libiberty)))
Hello, The lto plugis are tied to the built GCC anyway, so there isn't much point to versioning them. * 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? From 6bf6b87887a8a5eb53ad409cd4aa32cb1ac50786 Mon Sep 17 00:00:00 2001 From: Jonathan Yong <10walls@gmail.com> Date: Sat, 28 Jun 2014 09:35:02 +0800 Subject: [PATCH 1/1] Cygwin/MinGW: Do not version lto plugins --- gcc/config.host | 6 +++--- lto-plugin/Makefile.am | 2 +- lto-plugin/Makefile.in | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)