From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 647A33851C03 for ; Fri, 22 Jan 2021 14:46:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 647A33851C03 Received: by mail-ej1-x636.google.com with SMTP id a10so7993871ejg.10 for ; Fri, 22 Jan 2021 06:46:40 -0800 (PST) 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=obsiiyWZWMjQkOh206BVIu07Q/siCjlNYEltF2XtRM4=; b=HEO72XfJYOXBaiCY4NeQEjah4/iFa+tIepPJBSb02Q4csKUOwyp7IhQlK+L28ehUfg YFe/UAeEmdjNW/PO5jb/p531+IGnygCPf5mebJuPQxPRdAAJBV0Nv/VfYbSa3mKyUO2w mVy0ftchwYco5yl6WHxMyvWl0XppmfvJxEY47lkxE+p8tZODGyrtLY3VcfdYoE6nmEeE EGxHeeVISIGSpPc1iZMyksvQB0jlFB16+3wQwm/HR0JcIJuODFRpvZr7G/KB8Gvt5fSp lFGo86LnnDCTLzt0hJjYuoztlG1hDsbsiGCPE5SzF9xtw7ofNOjBaqq2czi3/o8R+O4f 4u7A== X-Gm-Message-State: AOAM5308jWoDIK1WEbgPhNMmBNMQLUWC613Nqc8Bn6/S7L4W+aKv7X0b x5fOs8toZ4Sfg1l5QZhyrroZIaeBHp29du/9QWw= X-Google-Smtp-Source: ABdhPJy+3O9vSNGaK4X8B4vlRg4ivDdTz5PKHdxge/0yJJMHehDOivATfG9a22uXcsdtPKA6ObYqnNpYEpwI9M8eeV8= X-Received: by 2002:a17:906:3b11:: with SMTP id g17mr3130795ejf.473.1611326799489; Fri, 22 Jan 2021 06:46:39 -0800 (PST) MIME-Version: 1.0 References: <20201207203033.GI2309743@redhat.com> <87sg8h8i2e.fsf@keithp.com> <20201207210659.GK2309743@redhat.com> <20210108182111.GE9471@redhat.com> In-Reply-To: <20210108182111.GE9471@redhat.com> From: Vladimir V Date: Fri, 22 Jan 2021 15:46:28 +0100 Message-ID: Subject: Re: Problem building libstdc++ for the avr target To: Jonathan Wakely Cc: Keith Packard , libstdc++@gcc.gnu.org X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, 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: Fri, 22 Jan 2021 14:46:42 -0000 Thank you for the detailed clarification. My primary idea was to reduce the build dependencies between hosted libstdc++ and target libc if some components can not be supported or never will be used. Also my general vision is that if something doesn't work it shouldn't be available in the environment. But I perfectly understand the rationale you explained and requirements applied by standard. So I think not much can be done here at this point and further work should be on the avr-libc side. Thank you. =D0=BF=D1=82, 8 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3. =D0=B2 19:21, Jonathan Wak= ely : > On 04/01/21 12:28 +0100, Vladimir V wrote: > >Hello and Happy New Year! > > > >Getting back to the discussion we had about scalable libstdc++. > >For sure it will be very helpful for embedded targets. There are huge > >components with > >well defined boundaries that are unlikely to be often used in minimalist > >settings but require missing platform support. > >One particular example I'm looking at right now is 'filesystem'. Althoug= h > >it resorts to some > >default stubs if corresponding API is not present, I think it would be > >correct to remove it from the library > >completely if it can not/should not be used on the target. > >In case of avr-libc it is worse as the unistd is partially present but n= ot > >sufficient to satisfy all filesystem > >dependencies. > > > >It looks like that after the filesystem support was implemented for c++1= 7 > >standard there is no option to remove > >it from the build (unlike for the filesystem-ts). Please correct me if I > am > >wrong but If it is like that I would like to make this configurable. > > You're right. > > My thinking was that the C++ standard requires the header > to be present for a hosted implementation. It doesn't necessarily > require the contents to *do* much, so it's conforming for them to > exist but always report errors. > > >Would it be acceptable? > > I'm unsure. > > Currently we support "hosted" and "freestanding", but not really > anything more fine-grained. The point of the configure switch > --disable-libstdcxx-filesystem-ts was not really to allow people to > build without it, but more to enable it for targets where it wasn't on > by default because it hadn't been tested yet. > > I've recently been trying to move away from having missing features, > and make things available unconditionally, but to use useless stubs or > return errors for targets that can't support it. For example, GCC 11 > always defines the std::thread type, even if the target can't actually > use it to create new threads. The idea is to always provide a complete > implementation, not have the feature set vary by target (I see a lot > of confusion on places like StackOverflow, where the answer is "yeah > sorry, that header is empty on your OS"). > > What you're suggesting would lead to a more modular libstdc++ where > you can enable/disable components, similar to what newlib does. If we > did that for more than just the std::filesystem library things would > get complicated (it increases the maintenance and testing burden, and > we need to be careful not to create dependencies on anything from a > conditionally-present feature). > > Would your suggestion actually result in smaller/faster binaries for > AVR? Or just remove features that aren't fully functional if you > attempt to use them? If having those features in the library doesn't > actually cause bigger/slower binaries, then I don't really see a > problem with them being present. > > Tangentially, the direction the C++ standard seems to be going is to > grow the feature set of freestanding. That would allow more things to > be used in freestanding environments, rather than the very limited set > of features currently guaranteed to be available. That doesn't really > help you though, as you want a hosted env with things like basic I/O, > but not the full set of features usually present for hosted. > > > >