Re: Linux vs. libio

[Jeffrey A Law <law at cygnus dot com>]

  In message <19991220163854A.mitchell@codesourcery.com>you write:
  > >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:
  > 
  >     Jeffrey> IMHO, even for development versions Mark needs to get the
  >     Jeffrey> glibc folks on board first or that work needs to happen
  >     Jeffrey> on a branch.
  > 
  > There are reasons to get the new ABI code in, even without libio
  > changes.  Such as anyone using GCC on an IA64 system needs those
  > changes.  They can get another free C++ iostreams library, like the
  > one from SGI, and use it instead of libio. 
Sorry.  IMHO, you must get the glibc folks on board before you can check in
these changes to libio.

If you want I'll ask for a formal vote from the steering committee.

 >  the new ABI work (in the compiler, not libio) is just like
  > adding support for the MIPS R10K, or for a new generic optimization,
  > or for a new language feature -- as long as it's not impacting the
  > rest of the compiler, and it's a good thing to do, it belongs on the
  > mainline, right?  This isn't like old-IA32 vs. new-IA32, or
  > old-fixinclude vs. new-fixincludes; there will never be a cutover from
  > the old ABI to the new ABI.  Instead, they'll both coexist, with a
  > switch to choose which one to use, for the forseeable future.
I've got no objection to the compiler side of the ABI work going into the
development tree.  My objections are with such changes going into libio
without prior approval from the glibc/libio folks.  I thought I had made
that clear.

jeff