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. >> >> >> >>