Re: Problem building libstdc++ for the avr target

[Jonathan Wakely <jwakely@redhat.com>]

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