[PATCH] Cygwin/MinGW: Do not version lto plugins

[PATCH] Cygwin/MinGW: Do not version lto plugins

[JonY]

[-- Attachment #1.1.1: Type: text/plain, Size: 349 bytes --]

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?


[-- Attachment #1.1.2: cb0598fe3c511e1d572c89db671c17838c60a2b3.txt --]
[-- Type: text/plain, Size: 2945 bytes --]

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(-)

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)))
-- 
2.11.4.GIT


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[Richard Biener]

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.

>

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 1298 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 1875 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[Richard Biener]

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.

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 340 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[Martin Liška]

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

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[Richard Biener]

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

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[Martin Liška]

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

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[Martin Liška]

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

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 271 bytes --]

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?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

[Martin Liška]

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