This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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


>>>>> "Geoff" == Geoff Keating <geoffk@cygnus.com> writes:

    >> From: Mark Mitchell <mark@codesourcery.com> Date: Sun, 19 Dec
    >> 1999 22:26:18 -0800

    >> However, libio has to change to match the new ABI.  That's a
    >> fact.  Obviously, this will be a conditionally compiled change;
    >> the compiler's going to be supporting the old ABI indefinitely.

    Geoff> I think you're misunderstanding the point.  You can't

I don't think so.

    Geoff> conditionally _compile_ anything.  You must make sure
    Geoff> everything will work at runtime, out of the same objects.
    Geoff> This is what 'binary compatibility' means.

Yes.  Let's try this again.

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*.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


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