This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: Linux vs. libio
- To: law at cygnus dot com
- Subject: Re: Linux vs. libio
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Mon, 20 Dec 1999 09:13:41 -0800
- Cc: martin at loewis dot home dot cs dot tu-berlin dot de, drepper at gnu dot org, gcc at gcc dot gnu dot org, libc-alpha at sourceware dot cygnus dot com
- Organization: CodeSourcery, LLC
- References: <199912201435.PAA01388@loewis.home.cs.tu-berlin.de><4717.945702435@upchuck>
>>>>> "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