Re: [PATCH 1/2] libstdc++: Add --enable-pure-stdio-libstdcxx option

[Keith Packard <keithp@keithp.com>]

[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]

Jonathan Wakely <jwakely@redhat.com> writes:

> GCC changelog files are autogenerated now, so patches should not touch
> them. Just include the ChangeLog entry in the Git commit log (which
> will usually end up being quoted in the patch and/or the email body of
> the mail to gcc-patches).

Awesome.

> I think the right way to do this (or at least, the way that was
> intended when basic_file_stdio.cc was added) is to provide a new file
> and change GLIBCXX_ENABLE_CSTDIO in acinclude.m4 to use that new file.
>
> The two biggest downsides of that are that it duplicates a lot of the
> file (because the diffs for your changes are small) and that the
> correct name for your new file is already taken!

I can definitely see a reason to use a separate file when implementing
the basic_file interface on top of something other than stdio, but
this patch doesn't do that -- it only changes the interaction between
basic_file and stdio in a few places.

I think it makes the best long-term sense to leave everything in
basic_file_stdio.cc and avoid having the two implementations diverge in
the future.

> However, it's rather late in the GCC 11 process to make a change like
> that (even though it's really just renaming some files). Would you be
> OK waiting until after GCC 11 is released (in 4-5 months) to do it
> "properly"? Is this blocking something that would require doing it
> sooner?

This patch enables the use of C++ with picolibc, a libc designed for 32-
and 64- bit embedded systems.

Right now, I'm working on getting picolibc support integrated into
Zephyr, which uses toolchains build by crosstool-ng. I've gotten
picolibc support merged to crosstool-ng, but the Zephyr developers are
interested in having a single toolchain support three different libc
implementations (newlib, newlib-nano and picolibc), but that's blocked
on having C++ support available in all three libraries.

So, you're at the bottom of my current dependency graph :-)

I don't particularly need this released in gcc, but I would like to
get patches reviewed and the general approach agreed on so that I can
feel more confident in preparing patches to be applied to gcc in
crosstool-ng itself.

Once that's done, I'll also be able to release new Debian packages of
GCC for embedded ARM and RISC-V and have those include suitable patches
so that we can support embedded C++ development there too. 

-- 
-keith

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]