[PATCH 2/2] ctype: use less short names in public header
Corinna Vinschen
vinschen@redhat.com
Fri Dec 3 09:56:04 GMT 2021
On Dec 2 11:27, Corinna Vinschen wrote:
> 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.
Reverted.
Corinna
More information about the Newlib
mailing list