Bug with gcvtf

Bug with gcvtf

[Rian Quinn]

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.

Rian

Re: Bug with gcvtf

[Joel Sherrill]

On Mon, Aug 26, 2019, 7:16 AM Rian Quinn <rianquinn@gmail.com> 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
>

Re: Bug with gcvtf

[Rian Quinn]

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.
Rian

On Mon, Aug 26, 2019 at 1:32 PM Joel Sherrill <joel@rtems.org> wrote:

>
>
> On Mon, Aug 26, 2019, 7:16 AM Rian Quinn <rianquinn@gmail.com> 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
>>
>

Re: Bug with gcvtf

[Joel Sherrill]

On Tue, Aug 27, 2019 at 7:27 AM Rian Quinn <rianquinn@gmail.com> 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 <joel@rtems.org> wrote:
>>
>>
>>
>> On Mon, Aug 26, 2019, 7:16 AM Rian Quinn <rianquinn@gmail.com> 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

Re: Bug with gcvtf

[Kota Uchida]

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 <joel@rtems.org>:
>
> On Tue, Aug 27, 2019 at 7:27 AM Rian Quinn <rianquinn@gmail.com> 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 <joel@rtems.org> wrote:
> >>
> >>
> >>
> >> On Mon, Aug 26, 2019, 7:16 AM Rian Quinn <rianquinn@gmail.com> 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