Re: [PATCH 2/2] ctype: use less short names in public header
Corinna Vinschen <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> wrote: > > > > > > > > On Tue, 30 Nov 2021 at 15:14, Corinna Vinschen <[email protected]> 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