Re: build glibc without support for utimensat/futimens and epoll?

[Florian Weimer <fweimer at redhat dot com>]

On 03/29/2018 04:58 PM, Carlos O'Donell wrote:
> On 03/29/2018 03:43 AM, Florian Weimer wrote:
> > On 03/23/2018 10:15 PM, Carlos O'Donell wrote:
> > > You cannot remove functions from glibc, they are part of the ABI and API.
> >
> > If that's the case, then why are you working on the sysroot linkage model? 8-)
>
> The sysroot linkage model, for those that don't know, is part of this project:
> https://fedoraproject.org/wiki/PlatformInterface, that I'm working on.
>
> The idea behind a sysroot linkage is:
>
> * How do we provide strong assurances that ABI/APIs are stable in a distribution
>    regardless of the installed glibc.
>
>    - You have two options to solve this, either link against a fixed ABI/API glibc
>      in a sysroot.
>
>    - Use something like libabigail to ensure you never deviate from ABI in a
>      released glibc.
>
> * How do we provide the ability to upgrade glibc without impacting what you link
>    against normally?
>
>    - Secondary goal would be to link against that new glibc.
>
> Within those goals I believe you are questioning:
>
> If you can't remove functions from glibc, then why work on providing alternate
> glibc's to link against?

I think a suitable sysroot would likely address Ben's need—upgrade the 
system glibc to 2.19 or whatever version is needed to run the desired 
applications, but continue to link your own programs against the sysroot 
glibc with version 2.3 (or whatever matches the original glibc version).

Or put differently, the primary motivation behind the sysroot linkage 
model is avoiding Ben's problem.

Thanks,
Florian