This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC viciously beaten by ICC in trig test!
zack@codesourcery.com (Zack Weinberg) wrote on 15.03.04 in <87y8q1a9nc.fsf@egil.codesourcery.com>:
> In the abstract, I think that *if* the "C language runtime" part of a
> C library were disentangled from the "low-level operating system
> interface" part, the "useful but nonstandard utility routines" part,
> and the "shared object loader" part, then it would be good to have a
> close relationship between the language runtime project and the
> compiler project. The other projects, however, ought to be prohibited
> from communicating with the language runtime and compiler teams except
> via standards committees. (They don't have to be formal and
> ISO-recognized or anything; an IETFish process would be fine.)
>
> This, however, will never happen (disentanglement would require
> redesigning the entire C library and bits of the language), and so I
> am in favor of generally distant relations between compiler and
> library teams.
Well, maybe it won't happen with glibc. OTOH, glibc doesn't seem to get
ported outside the Linux/Hurd universe anyway.
For the rest of the world, if someone wanted to create a "portable C
library", this seems like the path to take. (Specifically, if you want to
be able to cope with such diverse OSes as Unix, VMS, and Windows, then
anything else seems insane.)
The interesting point is, in fact, defining useful interfaces between
those parts.
(A few asides:
"useful but nonstandard utility routines"
libg (in analogy to libg++)?
"shared object loader"
libgcc+binutils+ld.so ... really, binutils belongs with gcc more
than glibc does.
Do not forget "locale and charset system" - that's neither low-level OS
interface, nor should it be part of "C language runtime" (because
there are OS-specific implementations), nor is it really "useful
but nonstandard utility routines". In fact, there may be more such
stuff than this ... maybe "high-level OS interface".
)
MfG Kai