From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 74CD03858006 for ; Fri, 8 Jan 2021 18:21:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 74CD03858006 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-588-zr2eDbEXPlmsQqHIo93maA-1; Fri, 08 Jan 2021 13:21:14 -0500 X-MC-Unique: zr2eDbEXPlmsQqHIo93maA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 83A38107ACE3; Fri, 8 Jan 2021 18:21:13 +0000 (UTC) Received: from localhost (unknown [10.33.36.155]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5DE031B4B0; Fri, 8 Jan 2021 18:21:12 +0000 (UTC) Date: Fri, 8 Jan 2021 18:21:11 +0000 From: Jonathan Wakely To: Vladimir V Cc: Keith Packard , libstdc++@gcc.gnu.org Subject: Re: Problem building libstdc++ for the avr target Message-ID: <20210108182111.GE9471@redhat.com> References: <20201207203033.GI2309743@redhat.com> <87sg8h8i2e.fsf@keithp.com> <20201207210659.GK2309743@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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 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, 08 Jan 2021 18:21:18 -0000 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'. Although >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 not >sufficient to satisfy all filesystem >dependencies. > >It looks like that after the filesystem support was implemented for c++17 >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.