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