This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc at the Toolchains microconference at LPC 2019
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.