[PATCH 2/2] ctype: use less short names in public header
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 <email@example.com> wrote:
> > >
> > > On Tue, 30 Nov 2021 at 15:14, Corinna Vinschen <firstname.lastname@example.org> 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.
More information about the Newlib