This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Linux vs. libio
In article <199912210311.TAA11055@localhost.cygnus.com> you write:
>> From: Mark Mitchell <mark@codesourcery.com>
>> Date: Mon, 20 Dec 1999 18:06:29 -0800
>
>> Geoff> So we need a libio in glibc which will work for _both_ the
>> Geoff> old ABI and the new ABI.
>>
>> If we can do this, that will be wonderful. I'm in no way opposed to
>> this, if it is technically feasible. I'll try to see how this might
>> be done.
>...
>> But, one of the vtables will contain thunks that adjust the this
>> pointer before calling through the real vtable. So there will be two
>> costs to just this level of compatibility: extra space, and extra
>> time. That seems undesirable to me.
>It's not like there is a _choice_. We must maintain backwards
>compatibility. If this costs in space/time, then that's unfortunate
>but we have to live with it (and try to minimize it, of course).
This makes for yet another good reason to avoid linux and glibc.
Rude ? Maybe.
I've followed the glibc issues from the sidelines.
Somehow, I don't quite believe that, no matter how well-meaning the glibc
folks have been, such disasters won't happen again...
Actually, I'm concerned about gcc and the steering committee position here.
I can understand that other FSF projects have a somewhat important influence
on gcc's life.
*However*, not all the world is FSF, there are other major users of gcc
outside of the glibc/linux worlds.
I'd like reassurance on the following point: assuming there is some change
in gcc that is necessary for the larger good of gcc (specifically, a modern
C++ ABI, without vtables/thunks related bugs, and liable to work correctly
from the start on IA64), that may mean some unpleasantness for glibc or
linux folks (like having to upgrade the glibc version number...), will the
Steering Committee take steps to ensure the Right Thing is done ?
Furthermore, if you believe you will be able to live forever with glibc having
the same major version number, I think you're going down a very dangerous
path.
Updates happen. Binary compatibility is not forever. Update paths should be
provided, but the show must go on, problems must be fixed, and sooner or
later, there is going to be no other possibility than break old stuff (or get
more bloat than Windows). As far as I understand, symbol versioning will
get you bloated systems/bloated libraries... ultimately a bad thing.
Whom does this help ?
* people for whom the update is too difficult,
* companies that distribute binary-only applications.
Both problems have real solutions: give people better tools to manage updates,
so that it becomes realistic for them to do so (notice how Windows makes
this automatic... even though I loathe windows),
and *don't* cater to companies that need such fine-grained binary
compatibility. They can either put updates out, or start playing open,
and work in a more system-frienly way.