From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 7EB633858001 for ; Thu, 25 Mar 2021 21:38:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7EB633858001 Received: by mail-ed1-x52d.google.com with SMTP id dm8so4091611edb.2 for ; Thu, 25 Mar 2021 14:38:03 -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=XHQLMIHbdViZq53zR7EAgfnfkBvry6eDT4oGfg8bA+U=; b=OgNgp7wQMm+ABb53DAvMypJQ3J5kNX1ILpt3nvD9+HqAj9K4BEWm9bftwCVx9EajGh Tg7cphqm7uxbOajyoGXKLV/+m3DC0jfQPr/1estaKOizXFaXoYOJurKvAAyP+DJStGvD tW7nHaiUubQJuzbzwDDZnGXxWwsBI51RpoKb4xg+Dt9bDvjvkTfU4alYaa//Tp7b+Qsu S5OMablhcFKgiZYXb++OqpVR75wW30RkJF9Ulg4VCwmpc8JFRVAX81xgxACckMwremjZ ABz4s0cqYJz68rZv6hZcyRnzn1S4BJLZlXArny0ic0SzjUFByZwrc8OASxNF4PYnariU ZmFA== X-Gm-Message-State: AOAM530vf80psdb89+gxQ7Z9P41OxAnjx42qEX8743EbVyip8nPSjSf2 MeYW4JOLTdWJfiQ8h7wimXeh4ES066PiDwe3sDw= X-Google-Smtp-Source: ABdhPJzTuHIKIyNH2BemVf1IeTNgicoEy22jRDir+sF1z17z/8I+DZa3C1U8IUeHejGX04kADtCrhFh+zXRmEpyfFfU= X-Received: by 2002:a50:f9c8:: with SMTP id a8mr11474032edq.270.1616708282602; Thu, 25 Mar 2021 14:38:02 -0700 (PDT) MIME-Version: 1.0 References: <20210108182111.GE9471@redhat.com> <20210208174539.GN3008@redhat.com> <20210208174707.GO3008@redhat.com> <20210209104756.GW3008@redhat.com> <20210325123603.GN3008@redhat.com> <20210325182709.GU3008@redhat.com> In-Reply-To: <20210325182709.GU3008@redhat.com> From: Vladimir V Date: Thu, 25 Mar 2021 22:37:51 +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=-8.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, 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 21:38:05 -0000 Thank you for the quick reply. I am wondering if the freestanding libstdc++ requires that only freestanding subset of the underlying libc is used? avr-libc has stdlib.h with malloc declaration but it is not 'visible' in this code. I was thinking that maybe something like that would work (works in my case): diff --git a/libstdc++-v3/include/c_global/cstdlib b/libstdc++-v3/include/c_global/cstdlib index 47b954cf2..f04fd08de 100644 --- a/libstdc++-v3/include/c_global/cstdlib +++ b/libstdc++-v3/include/c_global/cstdlib @@ -43,7 +43,8 @@ #ifndef _GLIBCXX_CSTDLIB #define _GLIBCXX_CSTDLIB 1 -#if !_GLIBCXX_HOSTED +#if !_GLIBCXX_HOSTED && !_GLIBCXX_HAVE_STDLIB_H + // The C standard does not require a freestanding implementation to // provide . However, the C++ standard does still require // -- but only the functionality mentioned in It includes the stdlib.h from target libc if it is present. =D1=87=D1=82, 25 =D0=BC=D0=B0=D1=80. 2021 =D0=B3. =D0=B2 19:27, Jonathan Wa= kely : > On 25/03/21 12:36 +0000, Jonathan Wakely wrote: > >On 25/03/21 10:27 +0100, Vladimir V wrote: > >>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' wa= s > >>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 t= he > >>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 mayb= e > >>some implicit conditions are involved? > >> > >>Could you please support me with this issue? > > > >I think this is needed: > > > >--- a/libstdc++-v3/libsupc++/new_opa.cc > >+++ b/libstdc++-v3/libsupc++/new_opa.cc > >@@ -54,6 +54,10 @@ extern "C" > > void *posix_memalign(void **, size_t alignment, size_t size); > > # elif _GLIBCXX_HAVE_MEMALIGN > > void *memalign(size_t alignment, size_t size); > >+#else > >+ // A freestanding C runtime may not provide "malloc" -- but there is = no > >+ // other reasonable way to implement "operator new". > >+ void *malloc (std::size_t); with GCC 7.5 > > Oops, there was a stray "with GCC 7.5" that got into my clipboard > there! > > I've pushed the attached patch, please test and confirm if it fixes > your problem. > > >