On Tue, May 11, 2021 at 06:07:19PM +0100, Jonathan Wakely via Gcc-patches wrote:
> > I'm not sure if the abort call is necessary since the link step already
> > fails with a multiple definition error (without the fix) even if the
> > function is defined with an empty body. But since Jakub included
Tested on x86_64-pc-linux-gnu, and also verified that generic_to_chars
> > is not visible from libstdc++.a. Does this look OK for trunk and the 11
> > branch?
>
> Now with a testcase:
>
> -- >8 --
>
> Subject: [PATCH] libstdc++: Remove extern "C" from Ryu so
gt; > >
> > > Tested on x86_64-pc-linux-gnu, and also verified that generic_to_chars
> > > is not visible from libstdc++.a. Does this look OK for trunk and the 11
> > > branch?
> >
> > Now with a testcase:
> >
> > -- >8 --
> >
>
ng with some declarations for never-defined functions that GCC
now warns about.
Tested on x86_64-pc-linux-gnu, and also verified that generic_to_chars
is not visible from libstdc++.a. Does this look OK for trunk and the 11
branch?
Now with a testcase:
-- >8 --
Subject: [PATCH] libstdc
rations for never-defined functions that GCC
> now warns about.
>
> Tested on x86_64-pc-linux-gnu, and also verified that generic_to_chars
> is not visible from libstdc++.a. Does this look OK for trunk and the 11
> branch?
Now with a testcase:
-- >8 --
Subject: [PATCH] libs
floating_to_chars.cc includes the Ryu sources into an anonymous
namespace as a convenient way to give all its symbols internal linkage.
But an entity declared extern "C" always has external linkage, even
from within an anonymous namespace, so this trick doesn't work in the
presence of extern "C", a
