This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Linux vs. libio



  In message <199912202336.PAA16416@atrus.synopsys.com>you write:
  > 
  > >   > 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 incompatibilitie
  > s
  > > 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.
And do you happen to know when the next release cycle is going to start?  Are
you going to volunteer to remove this code if the release cycle starts before
glibc & gcc have merged their libio implementations?  Are you going to
volunteer to merge the two versions if Mark & CodeSourcery ultimately do not
do the work?

IMHO, even for development versions Mark needs to get the glibc folks on board
first or that work needs to happen on a branch.


  > 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.
All this can be easily done on a branch.

  > 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).
Yup.  If we can do this, then all my objections are removed.  Ultimately this
is what I want -- Mark, CodeSourcery, Uli & the glibc team to agree on
a technical plan and work together to make it happen and keep the glibc
and gcc sources in sync.  That *must* happen eventually anyway, or everything
Mark & CodeSourcery are doing will end up being tossed into the trash can.

  > 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.
Right.  That's precisely what needs to happen short and long term.  It's
the right thing to do.  While they are working towards such a solution Mark
and CodeSourcery are free to work on a branch to expose the code to additional
testers.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]