Re: Linux vs. libio

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

  In message <19991220150459I.mitchell@codesourcery.com>you write:
  > Let's suppose we're running on IRIX.  There's no libio in libc.
  > 
  >   o Now, we can compile with the old C++ ABI or the new C++ ABI.  
  >     Either is OK -- there's no standard C++ ABI on IRIX.  The user
  >     might choose this which ABI to use at compiler-configuration time.
  > 
  >     But, the libio in libstdc+++ needs to know about the C++ ABI
  >     (that's a design choice in libio).  So, we need to make the libio
  >     in libstdc++ do its by-hand layout of C++ objects in the same 
  >     way as the C++ compiler.  Which way to do this is known to us
  >     when we build libio; we've already committed to the C++ ABI to
  >     use.  Depending on which way the user configured the compiler,
  >     we'll end up with different versions of libio.
  >     
  >   o On Linux, life is more difficult -- libstdc++ and glibc know
  >     about each other.
  > 
  >     I was thinking that *in principle* one could set up libio
  >     in libstdc++ analagously to the IRIX situation.  In particular,
  >     without knowing glibc, just as we do on IRIX.  Of course, one
  >     would only do this for the new ABI, and only when the system
  >     libc doesn't already contain the new libio.
  > 
  >     It may be that this is technically infeasible.  It's certainly
  >     not wrong in principle -- it's in fact the only way to let people
  >     use the new ABI without upgrading their C library.
  > 
  > To quote Nixon :-), "let me make one thing perfectly clear":
  > 
  >   o I'm not proposing changing *anything* about libio when compiled
  >     with the existing C++ ABI, which will continue to be supported
  >     indefinitely.
  > 
  >   o I'm proposing chaning libio, conditionally, when compiled with the
  >     new C++ ABI.  (This is analagous to multilibbing.)  Without doing
  >     so, it will not work.
  > 
  > The entirety of a single C++ program must be compiled using -fnew-abi,
  > or -fno-new-abi -- you can't compile bits and pieces one way.  If you
  > want to have a library that can be linked with the old ABI and the new
  > ABI, you compile it twice: once to support the old ABI and once to
  > support the new one.
  > 
  > That's no different for libio, since it is emulating the C++ ABI, even
  > though it is written in C.
  > 
  >     >> It would be nice if people can use the new ABI, if only to test
  >     >> it, on IA32 Linux.  They can't do that unless we can produce a
  >     >> version of libio that doesn't interact with the C library,
  >     >> since we can't expect everyone to go upgrading their C library.
  > 
  >     Geoff> Why not?  If the new ABI is stable (or stable enough for
  >     Geoff> libio), there is no reason not to simply tell people "gcc
  >     Geoff> version foo requires glibc version bar".
  > 
  > That's not very polite.  That means people with legacy Linux systems
  > can't use the advances in the compiler.  But, what you say is
  > possible.
  > 
  > However, we *still* have to change libio for other, non-Linux systems
  > -- or else nobody can use the new ABI *anywhere*.
All this is fine and good *as long as you can get Uli and the glibc folks to
agree to the change*.  I'm not going to support diverging our libio sources
from the glibc libio sources.  Even in the development tree.  That ultimately
is a lose.

I'll repeat, if you can get Uli & friends to agree to the change, then it can
go into the development sources.  If not, then it must not go into the
development sources (it can of course still go on a branch).


jeff