From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id D13D43857C50 for ; Thu, 25 Mar 2021 09:27:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D13D43857C50 Received: by mail-ed1-x536.google.com with SMTP id bx7so1570925edb.12 for ; Thu, 25 Mar 2021 02:27:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4OnddpSNXmh5ECFB2W9jsWiZZqsCrDqKhAExMSHrlAs=; b=rWEX6CagNvNWrLyxgfaP9Pr9mVIdrTX4Stzp2izQDPB1tlIEVJKPGwfyCiMgeAR/t4 XT79cTdI/i5vcllNbA16N91taS9wJRwThgUQrbv2zOhO/aTqba1RYUz8vX9Y0WPGh2Hu AU5VEuxxsXSKaTPUMuDBLxnJr2lN7Dgq/7XGhbIAJaWx3uvqrq46DPSDp454tuKuZbtS QpWjDIoolEc1SDJbHXa2N9xWrxfu/TXrtA+C0EVPAFGg0YNjTYDkg8Jx9GvF5wNYEPg3 ymNdlCg13ppiJ9xV5rYiqrQauiR9QRHcfh8NZfF08RMxIq+zGq+pIqpRlHXQikakNzSb pwLg== X-Gm-Message-State: AOAM533n4orQuRZDYEO5eqGDopLtqRfMEIa5GeoGn+8P1T4HMFPjGS8h wNrL7i5l60wj9RQoPLY4bJ28hvQoAFTtnB7MFmUjSP2vG2o= X-Google-Smtp-Source: ABdhPJw8Upqafsut/DPkCujuZWqMbgEc3626qSpLz019SiSNGzU8m5nzz6p6x3jwZ4+N00CfZ3rInbtK01agxJ5nCgE= X-Received: by 2002:a05:6402:35c9:: with SMTP id z9mr8010668edc.94.1616664448006; Thu, 25 Mar 2021 02:27:28 -0700 (PDT) MIME-Version: 1.0 References: <20201207203033.GI2309743@redhat.com> <87sg8h8i2e.fsf@keithp.com> <20201207210659.GK2309743@redhat.com> <20210108182111.GE9471@redhat.com> <20210208174539.GN3008@redhat.com> <20210208174707.GO3008@redhat.com> <20210209104756.GW3008@redhat.com> In-Reply-To: From: Vladimir V Date: Thu, 25 Mar 2021 10:27:16 +0100 Message-ID: Subject: Re: Problem building libstdc++ for the avr target To: Jonathan Wakely Cc: libstdc++@gcc.gnu.org X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 09:27:30 -0000 Hello. Recently I tried the 'freestanding' build of the libstdc++ for the avr to verify that my fixes were sufficient for it as well. Unfortunately, I encountered the following error: ../../../../libstdc++-v3/libsupc++/new_opa.cc: In function 'void* __gnu_cxx::aligned_alloc(std::size_t, std::size_t)': ../../../../libstdc++-v3/libsupc++/new_opa.cc:97:28: error: 'malloc' was not declared in this scope 97 | void* const malloc_ptr =3D malloc(sz + al); My investigation showed that in the chain of includes the stdlib.h of the avr-libc is not present. It looks like includes are resolved in the following way (here are the original paths as they are linked from out folders during build): new_opa.cc -> libstdc++-v3/include/c_compatibility/stdlib.h -> libstdc++-v3/include/c_global/cstdlib In cstdlib, for non-hosted builds stdlib.h is not included. This problem is not present if the non-hosted build is done with 'with-newlib' flag instead of 'with-avrlibc' (common workaround as the avrlibc build was fixed only recently). Might it be that some include order depends on the target libc? Or maybe some implicit conditions are involved? Could you please support me with this issue? Thank you. =D0=B2=D1=82, 9 =D1=84=D0=B5=D0=B2=D1=80. 2021 =D0=B3. =D0=B2 11:54, Vladim= ir V : > Thank you for the review. > > > My best guess is that it is there because that file previously used > > lstat and the linux lstat(2) man page (IMHO incorrectly) says that > > is needed. > > I got the same feeling as well. > > > > =D0=B2=D1=82, 9 =D1=84=D0=B5=D0=B2=D1=80. 2021 =D0=B3. =D0=B2 11:48, Jona= than Wakely : > >> On 08/02/21 23:25 +0100, Vladimir V wrote: >> >Thank you for the reply. >> > >> >>> I don't see why this file includes , it doesn't *seem* to >> >>> need it. Even if it's needed, the correct way to include it is: >> > >> >So it was there since the initial commit but during my quick walk throu= gh >> >the history >> >I didn't find what API from was used. >> >> My best guess is that it is there because that file previously used >> lstat and the linux lstat(2) man page (IMHO incorrectly) says that >> is needed. >> >> >So, in the patch I just deleted the include but as Keith suggested it c= an >> >affect the client code. >> >If the policy is: >> > >> >>> We routinely remove such transitive includes. Any code assuming that >> >>> defines the contents of is wrong and should be >> >>> fixed. >> > >> >then I would keep it like that. >> >Or would it be better to update the patch to move it inside the guard? >> >> I will commit your patch unchanged. In practice it is unlikely to >> affect anybody, because that header is only used when compiling >> libstdc++ itself. I don't see any code in the Debian archives using it >> except for GCC itself and one testcase in the Clang repo. >> >> >>