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
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?
signature.asc
Description: OpenPGP d
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 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
On Mon, Sep 21, 2020 at 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
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 mast
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
ae6cf62861b5e9acb5
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
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> The lto plugis are tied to the built GCC anyway, so th
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
>> 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
On 9/9/20 7:21 AM, Richard Biener wrote:
> On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches
> 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, instea
On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches
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 plug
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
12 matches
Mail list logo
