Re: Bug with gcvtf

I've already sent a patch on Tue, 23 Jul 2019.
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=9cde02051ea528e5f1af1aa2dea50224eec57860

2019年8月27日(火) 21:39 Joel Sherrill <[email protected]>:
>
> On Tue, Aug 27, 2019 at 7:27 AM Rian Quinn <[email protected]> wrote:
> >
> > I was using the latest Newlib 3.1 and Libc++ 9.0. I have not checked the master branches, but if that is what you are looking for, I would be more than happy to check that out as well. Just let me know. I will say that in the past I have had to make a lot of mods and that does not seem to be the case anymore, with either project. Other than this one fix, everything seems to work out of the box.
>
> Sorry. This file didn't originate in NetBSD or FreeBSD like many files
> in newlib did.
> The implementation is newlib specific so just submit a patch.
>
> --joel
>
> > Rian
> >
> > On Mon, Aug 26, 2019 at 1:32 PM Joel Sherrill <[email protected]> wrote:
> >>
> >>
> >>
> >> On Mon, Aug 26, 2019, 7:16 AM Rian Quinn <[email protected]> wrote:
> >>>
> >>> The "gcvtf" function in newlib/newlib/libc/stdlib/efgcvt.c is in the file
> >>> before gcvt, but relies on it with an implicit definition. When attempting
> >>> to compile Newlib on x86_64 for Libc++ support, I get a compile error as
> >>> the definitions of the implicit version does not match the actual version.
> >>> To fix the issue, all I had to do was to place the gcvtf version _after_
> >>> the implementation of gcvt and it compiles fine.
> >>
> >>
> >> Can you find the upstream source of this file and see if it has this change and possibly others?
> >>
> >> I don't doubt the change is needed but this sounds like a hint to see if we are.in sync with the upstream.
> >>
> >> Thanks.
> >>
> >> --joel
> >>>
> >>>
> >>> Rian