Re: Linux vs. libio

[Geoff Keating <geoffk at cygnus dot com>]

> From: Mark Mitchell <mark@codesourcery.com>
> Date: Mon, 20 Dec 1999 15:04:59 -0800

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

In principle, it would be better to have libio and IRIX libc know
about each other.  Unfortunately, this isn't practical.  Under GNU
operating systems (OSs using glibc) this is possible, and very
desirable.

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

This is what I'm objecting to.  Perhaps I should draw a diagram.  I
expect that with -fnew-abi, the version number of libstdc++ will
change, perhaps to libstdc++.so.3.  Now, suppose I use my brand new
GCC 3.0.0, with -fnew-abi on by default, under my linux system,
to compile an executable 'test', and 'netscape' is an old binary-only
application compiled under the old GCC.

So we have a shared library use graph that looks like this:

netscape --> libstdc++.so.2.8 --> libc.so.6
test	 --> libstdc++.so.3   ----^

But this won't work with your proposal.  I can have the libio in
libc.so.6 compiled with the new C++ ABI, in which case the old
libstdc++ won't work, or it can be compiled with the old ABI in
which case the new libstdc++ won't work.

It is the glibc maintainers' policy to never again change the libc
version number if we can possibly help it.  Bad things happen when you
do this.  We (think we) have sufficient mechanisms in glibc to avoid
needing to do this, for instance symbol versioning.

So we need a libio in glibc which will work for _both_ the old ABI and
the new ABI.

Maybe we don't need it right now; for testing purposes, it may not
matter that the libio in libc and libstdc++ don't interoperate.  In
the long run, though---and that means before -fnew-abi becomes the
default in any release---we will need a libio that works for both libc
and libstdc++.  We will need to make a glibc release with this libio
at the same time as, or preferably before, the gcc release which
switches to the new ABI.  Given the lead times involved, you will
really want to be working on this now if you want the switch to happen
before 2001.

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

No, this gives you two libraries.  You have to do something more
complicated if you only want one library.  Hopefully the new C++
symbol mangling and the old one don't overlap so the 'more
complicated' just means specifying both versions of the object files
on the link line.

> That's no different for libio, since it is emulating the C++ ABI, even
> though it is written in C.

libio is special because it is part of glibc.  The C++ ABI changes at
pretty frequent intervals, the C ABI doesn't.

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

This is not a new thing.  People with legacy Linux systems can't use
advances in the kernel unless they upgrade their libc, nor can they
run programs that were built under newer versions of the libc.  In
this case, they just won't be able to use the new ABI until they
upgrade, which probably won't cause them much pain.

-- 
- Geoffrey Keating <geoffk@cygnus.com>