Re: glibc at the Toolchains microconference at LPC 2019

[Carlos O'Donell <carlos at redhat dot com>]

On 6/27/19 1:21 PM, Florian Weimer wrote:
> * Zack Weinberg:
> 
>> I specifically disagree with this.  The existence of these dedicated
>> libraries does not mean that there is no need for a minimal wrapper in
>> the C library.  In fact, providing a minimal wrapper in the C library
>> would make the implementation of dedicated libraries easier, since
>> they can concentrate on designing their higher-level API rather than
>> wasting engineering effort on system call wrappers.  glibc has already
>> done all of the low-level work necessary.
> 
> We would have to begin backporting syscall wrappers, though.  Otherwise
> these libraries are blocked until a glibc upgrade, which may not happen
> any time soon.

Correct.

> Maybe we can move well-established libraries into glibc eventually, but
> that can have unpredictable results if those libraries did not use
> symbol versioning from the start (so that their implementation
> interposes a newer glibc implementation for the entire process).

I don't think anyone is asking for this, but it will be a question that
comes up when established practice is migrated to glibc.

How did libstdc++'s adoption of boost APIs handle this? I think they
just renamed things?

> But I don't know if this (no syscall wrappers except in glibc) works as
> a default policy.

I didn't read Zack's comment as meaning "no syscall wrappers *except* in glibc,"
but "users can trust glibc to *always* provide syscall wrappers" in that we
as a community should not shirk our duty to provide syscall wrappers because
project X, Y, or Z says they will do it for us or are already doing it as
part of some userspace interface. There will always be users that want that
minimal C-callable interface.

-- 
Cheers,
Carlos.