On Fri, 14 Mar 2014, Rainer Orth wrote:
> Rainer Orth writes:
>
> >>> > For this particular case at least.
> >>> >
> >>> > Note that I'm not against linking against static libgcc_s for
> >>> > lto-plugin. The -static-libstdc++ we use is just because during
> >>> > bootstrap picking up the corre
Rainer Orth writes:
>>> > For this particular case at least.
>>> >
>>> > Note that I'm not against linking against static libgcc_s for
>>> > lto-plugin. The -static-libstdc++ we use is just because during
>>> > bootstrap picking up the correct libstdc++ was deemed too hard
>>> > to implement and
Richard Biener writes:
>> Exactly my words. But gcc provides zero help for that. All proposed
>> workarounds (having every user of gcc set LD_LIBRARY_PATH, messing
>> around with ldconfig or equivalent, having every single compiler user
>> provide -rpath/-R on his own) are usability or function
On Thu, 13 Mar 2014, Rainer Orth wrote:
> Richard Biener writes:
>
> >> > So then if it succeeds to link to a shared libgcc_s then why
> >> > is it not able to find that later? Maybe you miss setting
> >> > of a suitable LD_LIBRARY_PATH to pick up the runtime for
> >> > your host compiler?
> >>
Richard Biener writes:
>> > So then if it succeeds to link to a shared libgcc_s then why
>> > is it not able to find that later? Maybe you miss setting
>> > of a suitable LD_LIBRARY_PATH to pick up the runtime for
>> > your host compiler?
>>
>> For the same reason that we use -static-libstdc++
On Wed, 12 Mar 2014, Rainer Orth wrote:
> Richard Biener writes:
>
> > On Mon, 10 Mar 2014, Rainer Orth wrote:
> >
> >> Richard Biener writes:
> >>
> >> > Ouch. But as lto-plugin is a host module it should link against
> >> > the host libgcc, no? During stage1, that is. So the question is
>
Richard Biener writes:
> On Mon, 10 Mar 2014, Rainer Orth wrote:
>
>> Rainer Orth writes:
>>
>> > It does use the host compiler for me, too.
>> >
>> >> but maybe _that_ is the issue for you? (see also how it uses
>> >> -static-libgcc, for me it doesn't even depend on libgcc_s)
>> >
>> > But as
Richard Biener writes:
> On Mon, 10 Mar 2014, Rainer Orth wrote:
>
>> Richard Biener writes:
>>
>> > Ouch. But as lto-plugin is a host module it should link against
>> > the host libgcc, no? During stage1, that is. So the question is
>> > why does it use the gcc/ compiler?
>> >
>> > For
On Mon, 10 Mar 2014, Rainer Orth wrote:
> Rainer Orth writes:
>
> > It does use the host compiler for me, too.
> >
> >> but maybe _that_ is the issue for you? (see also how it uses
> >> -static-libgcc, for me it doesn't even depend on libgcc_s)
> >
> > But as you can see above, libtool, being it
On Mon, 10 Mar 2014, Rainer Orth wrote:
> Richard Biener writes:
>
> > Ouch. But as lto-plugin is a host module it should link against
> > the host libgcc, no? During stage1, that is. So the question is
> > why does it use the gcc/ compiler?
> >
> > For me it's using the host gcc:
> >
> >
Rainer Orth writes:
> It does use the host compiler for me, too.
>
>> but maybe _that_ is the issue for you? (see also how it uses
>> -static-libgcc, for me it doesn't even depend on libgcc_s)
>
> But as you can see above, libtool, being its usual helpful self, simply
> drops -static-libgcc ;-(
Richard Biener writes:
> Ouch. But as lto-plugin is a host module it should link against
> the host libgcc, no? During stage1, that is. So the question is
> why does it use the gcc/ compiler?
>
> For me it's using the host gcc:
>
> gcc -DHAVE_CONFIG_H -I. -I/space/rguenther/tramp3d/trunk/l
On Sat, 8 Mar 2014, Rainer Orth wrote:
> Richard Biener writes:
>
> > The following patch addresses the common (?) issue of people
> > omitting -flto from the linker command-line which gets more
> > severe with GCC 4.9 where slim LTO objects are emitted by
> > default. The patch simply _always_
Richard Biener writes:
> The following patch addresses the common (?) issue of people
> omitting -flto from the linker command-line which gets more
> severe with GCC 4.9 where slim LTO objects are emitted by
> default. The patch simply _always_ arranges for the linker
> plugin to be used, so if
> On Thu, 6 Mar 2014, Jan Hubicka wrote:
>
> > > On Tue, 4 Mar 2014, Jan Hubicka wrote:
> > >
> > > > >
> > > > > The following patch addresses the common (?) issue of people
> > > > > omitting -flto from the linker command-line which gets more
> > > > > severe with GCC 4.9 where slim LTO object
On Thu, 6 Mar 2014, Jan Hubicka wrote:
> > On Tue, 4 Mar 2014, Jan Hubicka wrote:
> >
> > > >
> > > > The following patch addresses the common (?) issue of people
> > > > omitting -flto from the linker command-line which gets more
> > > > severe with GCC 4.9 where slim LTO objects are emitted by
> On Tue, 4 Mar 2014, Jan Hubicka wrote:
>
> > >
> > > The following patch addresses the common (?) issue of people
> > > omitting -flto from the linker command-line which gets more
> > > severe with GCC 4.9 where slim LTO objects are emitted by
> > > default. The patch simply _always_ arranges
On Tue, 4 Mar 2014, Jan Hubicka wrote:
> >
> > The following patch addresses the common (?) issue of people
> > omitting -flto from the linker command-line which gets more
> > severe with GCC 4.9 where slim LTO objects are emitted by
> > default. The patch simply _always_ arranges for the linker
> Am 04.03.2014 13:30, schrieb Markus Trippelsdorf:
> > What is missing is a big fat warning in
> > http://gcc.gnu.org/gcc-4.9/changes.html that one should use the gcc
> > binutils wrappers (gcc-ar, etc.) when building projects with LTO.
>
> Is this enough? Or should the autoconf macros changed t
Am 04.03.2014 13:30, schrieb Markus Trippelsdorf:
> What is missing is a big fat warning in
> http://gcc.gnu.org/gcc-4.9/changes.html that one should use the gcc
> binutils wrappers (gcc-ar, etc.) when building projects with LTO.
Is this enough? Or should the autoconf macros changed to look for t
> On 2014.03.04 at 13:00 +0100, Richard Biener wrote:
> >
> > The following patch addresses the common (?) issue of people
> > omitting -flto from the linker command-line which gets more
> > severe with GCC 4.9 where slim LTO objects are emitted by
> > default. The patch simply _always_ arranges
>
> The following patch addresses the common (?) issue of people
> omitting -flto from the linker command-line which gets more
> severe with GCC 4.9 where slim LTO objects are emitted by
> default. The patch simply _always_ arranges for the linker
> plugin to be used, so if there are any (slim) L
On 2014.03.04 at 13:00 +0100, Richard Biener wrote:
>
> The following patch addresses the common (?) issue of people
> omitting -flto from the linker command-line which gets more
> severe with GCC 4.9 where slim LTO objects are emitted by
> default. The patch simply _always_ arranges for the link
23 matches
Mail list logo
