Re: Linux vs. libio

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    >> To get it working at all, he must change libio, and he wants to
    >> avoid rebuilding his Linux distribution to do so. I cannot find
    >> anything unwise here.

    Jeffrey> He's more than welcome to do this on his local box.  But
    Jeffrey> it's not something that belongs in our source tree.

Yes, it does.  There are three distinct things happenning here:

  o Implementation of -fnew-abi.

    We all agree this is a Good Thing.  Which platforms use it by
    default, when they do so, etc., is not something I've got any
    feelings about.  But, we want the new ABI to exist, and it will
    be the default ABI on IA64, I assume, since that's the ABI
    specified there.

    So, this goes in the tree.

  o Adjustments to libio.

    The current libio *will not work* without modification with the
    new ABI, even on non-Linux systems.  Suppose you're running 
    IRIX, and suppose you want to use the new ABI.  Or suppose
    you're running IA64 and you have to use the new ABI.  You need
    a modified libio.
    
    Of course, we need to conditionally compile the changes so that
    old ABI systems (like RH Linux) still work.  But, we can't
    support the new ABI without these changes, so they need to 
    go in the tree.

  o Configury changes to that building with -fnew-abi, on a Linux
    sytem using a glibc that contains a libio built with the old
    ABI, leaves you with a working compiler.

    If someone configures their tree using -fnew-abi on, say,
    RH 6.x, they'll get a totally non-working libio unless we
    turn on the new ABI in libio.  If that conflicts with the C
    library, and we don't sort out that interaction, they'll be hosed.

    There's no reason to say that people on IA32 Linux can't use
    the new ABI.  Just because libio happens to be in libc shouldn't
    (abstractly) sentence them to a worse fate than people running
    IRIX (where libio is not in libc).  The libio library knows how
    to deal with a "foreign" libc, and it should be possible to treat
    glibc as "foreign".  It may or may not be technically feasible
    to achieve this.

    I would argue that if it is achievable, this hunk should go in the
    tree as well.

I know there may be adverse consequences on performance as a result,
and I fully agree that the desirable configuration is to have a libc
and libstdc++ that share a libio.  But, for non-glibc systems we need
a solution, and for IA32 Linux I don't see why we shouldn't support
-fnew-abi configurations, if that's possible.

Believe it or not, I am not a *complete* idiot.  I'm not going to
somehow go breaking every Linux system on the planet, or something.

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