From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66163 invoked by alias); 27 Aug 2019 12:39:21 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 66155 invoked by uid 89); 27 Aug 2019 12:39:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:CANmpu8, quinn X-HELO: mail-oi1-f179.google.com Received: from mail-oi1-f179.google.com (HELO mail-oi1-f179.google.com) (209.85.167.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Aug 2019 12:39:20 +0000 Received: by mail-oi1-f179.google.com with SMTP id o6so14770050oic.9 for ; Tue, 27 Aug 2019 05:39:19 -0700 (PDT) Return-Path: Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com. [209.85.210.50]) by smtp.gmail.com with ESMTPSA id r2sm4898287otk.49.2019.08.27.05.39.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Aug 2019 05:39:17 -0700 (PDT) Received: by mail-ot1-f50.google.com with SMTP id z17so18435952otk.13 for ; Tue, 27 Aug 2019 05:39:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Tue, 27 Aug 2019 12:39:00 -0000 Message-ID: Subject: Re: Bug with gcvtf To: Rian Quinn Cc: Newlib Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019/txt/msg00509.txt.bz2 On Tue, Aug 27, 2019 at 7:27 AM Rian Quinn 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 t= han happy to check that out as well. Just let me know. I will say that in t= he past I have had to make a lot of mods and that does not seem to be the c= ase 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 wrote: >> >> >> >> On Mon, Aug 26, 2019, 7:16 AM Rian Quinn wrote: >>> >>> The "gcvtf" function in newlib/newlib/libc/stdlib/efgcvt.c is in the fi= le >>> before gcvt, but relies on it with an implicit definition. When attempt= ing >>> 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 versi= on. >>> 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 cha= nge 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