This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should glibc stand for "GNU Core Library?"


On 12/12/2016 03:42 PM, Stan Shebs wrote:
> On Fri, Nov 25, 2016 at 3:34 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> Every time I speak publicly about glibc I have to explain
>> that it's not just an ISO C library, we have BSD APIs, GNU APIs,
>> POSIX APIs, networking APIs, identity management APIs, OS APIs
>> (syscall wrappers), etc.
>>
>> Does "The GNU C Library" encompass the whole of the project?
>>
>> Just like GCC went from "The GNU C Compiler" to "The GNU Compiler
>> Collection"... should glibc move from "The GNU C Library" to
>> something like "The GNU Core Libraries" since the project provides
>> key core libraries that provide much more than just ISO C.
>>
>> Thoughts?
> 
> While the rationale makes sense, "core" is a rather an overloaded
> term, and often taken to mean "functionality that is not really
> required, but that every programmer probably wants to use", while a C
> library includes functions that are specified by the definition of the
> language.
> 
> Glibc is also inherently C-specific, in that proposals to add Fortran,
> or Go, or Common Lisp functions are not likely to be viewed favorably.
> :-)

Not so.

We have support functions for the C++ runtime to register destructors,
and if we needed anything to better enable other languages we would
consider it.

Fortran, particularly gfortran, makes direct use of libc.so.6 in any compiled
binary.

Likewise clisp depends on libc.so.6 also.

Only Go (go-lang) has the potential to run in a completely contained way
if you avoid any identity management APIs e.g. NSS, which if you do use, then
you are linked to libc.so.6 again.

So in many ways glibc _is_ core for all of the languages you listed (and many
other language interpreters).

I think that any API additions for other languages would be reviewed on
their technical merit e.g. Why aren't they in a language support library? Why
glibc? Commonly used feature by multiple languages?

> When I describe it, I just say "C library on steroids", and people
> seem generally content.

That's a limited view of the library.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]