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 <199912210049.QAA17857@atrus.synopsys.com>you write:
  > I wrote:
  > 
  > > 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.
  > 
  > Jeff writes:
  > 
  > > 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 be
  > fore
  > > 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?
  > 
  > Is this rhetorical or do you mean it?  In case you do mean it:
  > If that extremely unlikely event occurred, I'd just ship the thing and no
  > one would care.
Both.  And people would care -- every time we've mucked around with the
internals of libio we've created problems.  I will not support installing
this kind of code into the development libio without the glibc folks getting
on board first.  Even if the code is only conditionally used.

libio is (in effect) an external set of sources that we just happen to keep
a copy of.  We should not be mucking around with it.  Doing so just makes
our life harder when we have to untangle the mess that making private changes
to libio creates.  I will not be a party to such stupidity.

Even if we think we've got the code 100% correct (ie the behavior only changes
for -fnew-abi), then I still consider it unacceptable to change libio without
prior consent from the libio folks.  No users's won't notice, but developers
that have to apply bugfixes, or bring in a new version of libio from glibc
will be affected in a negative way.  Merges suck in a major way.  We've
managed to kill the last need for a merge when we picked up the remaining
gcc2 changes.  Let's not introduce new merge requirements.

  > Nevertheless, we're in violent agreement: the way to proceed is to start
  > out with a separate branch, then work on patches that all can accept.
Right.  So are you and I agreed, get the code onto a branch to help facilitate
development until Mark & Uli can come to an agreement on how to handle the
libio changes?

jeff


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