[PATCH 2/2] ctype: use less short names in public header
Corinna Vinschen
vinschen@redhat.com
Thu Dec 2 10:27:08 GMT 2021
On Nov 30 17:52, Richard Earnshaw wrote:
> On 30/11/2021 17:15, Jonathan Wakely wrote:
> > On Tue, 30 Nov 2021 at 17:12, Jonathan Wakely <jwakely@redhat.com> wrote:
> > >
> > > On Tue, 30 Nov 2021 at 15:14, Corinna Vinschen <vinschen@redhat.com> wrote:
> > > > Is there a good reason to revert these patches in newlib? I see the
> > > > problem but I'm unclear on how problematic the change is in real life.
> > >
> > > You cannot use newlib from Git to build any released version of GCC.
> > >
> > > Is building newlib from Git only supported when using GCC trunk, or is
> >
> > Oops, I mean building *against* newlib from Git, not building newlib
> > itself. You can still build newlib itself, because it doesn't use C++.
> > But you can't build a GCC 11.2.0 compiler that uses the latest newlib
> > from Git as its libc.
> >
> > > it supposed to build with e.g. GCC 11.2.0 from July this year? If yes,
> > > then newlib needs changes (whether reverting the change entirely, or
> > > just making another change to restore the old names in addition to the
> > > new ones).
> >
>
> My concern is that the proposed workaround may break other (probably buggy)
> apps that have been relying on the old BSD internal API for 30 odd years.
> The proposed workaround only solves the issue for G++.
I'm inclined to revert 3ba1bd0d9db, given it solves a problem which
isn't actually a problem in newlib, but in an application not following
the standards in terms of reserved symbols.
I'm discussing this with Jeff, stay tuned.
Corinna
More information about the Newlib
mailing list