Slightly corrected comment in the patch. вс, 7 февр. 2021 г. в 14:55, Vladimir V : > Hello, > > I finally managed to test building for AVR with Keith's patch and > unistd.h removed (to enforce usage of stabs in filesystem). > > I identified a couple of minor build issues that are obvious from the > attached patch, Could you please have a look? They work with AVR target > and doesn't seem to cause regressions for x64 build. > > Thank you. > > пт, 22 янв. 2021 г. в 15:46, Vladimir V : > >> 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. >> >> пт, 8 янв. 2021 г. в 19:21, Jonathan Wakely : >> >>> 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. >>> >>> >>> >>>