Re: Linux vs. libio

[Joe Buck <jbuck at synopsys dot COM>]

>   > It isn't really required that libio and glibc change in lockstep.  It
>   > certainly doesn't matter on platforms that don't use glibc.

> Huh?  If you don't change them in lockstep you introduce incompatibilities
> between the version in the linux C library and the version in GCC.  That
> has proven to be a majorly stupid thing to do.  We don't want to repeat
> that mistake again.  So I'll repeat.  They must change in lock step.

If glibc and libstdc++ are to share the same structures for streams/stdio,
then yes, they must change in lock-step.  This is appropriate for
*released* versions.  But for *testing*, it would be nice to have the
*option* on Linux of saying "don't share i/o structures".  Enabling this
option would break programs that rely on the C++ standard's guarantee that
cout/stdout and cerr/stderr are synchronized (unless flush calls are
inserted at appropriate points), and we would never build binary packages
to be distributed in that way, though we could point users to this choice
if they are stuck, trying to get new C++ code to run on a legacy Linux
system, for instance.

Ideally, this option would not represent a fork because we could find
an agreed-apon way to do this (agreeable to both the C++ and glibc teams).

>   > Why should we make it hard for people to test the new ABI?
> Why should we diverge from glibc?  That just makes our life more difficult.
> 
> You've got find another way which doesn't cause our libio to diverge from
> the one in glibc.  No ifs ands or buts about it.

It appears that the only way to get past this impasse is to find a libio
patch that the glibc folks would be willing to accept.