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

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

On 03/29/2018 10:04 AM, Florian Weimer wrote:
> 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).

I think that Ben doesn't need glibc 2.19 at all.

Ben appears to be building a newer version of Perl, Python 3, and X
from scratch.

You have one of two options for that rebuild:

(a) Using the existing CentOS 5 system tools.

or 

(b) Using a sysroot with newer tools you built.

I will assume that (a) turned out to be too old to build the needed
new software without custom patching.

However, it *also* turns out that the new software, even when built
with (b) makes assumptions about functioning APIs without checking
error returns. This failure mode is very common, and you and I have
discussed this as the primary reason we don't backport things into
older Fedora releases where packages may unconditionally enable support
for features the kernel doesn't yet have e.g. backport O_TMPFILE constants
while we wait for the kernel to backport the support.

So the sysroot linkage model does not help here in the traditional way
it is to be applied.

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

I assume that Ben could not build Perl, Python 3, and X with the system
tools because they were too old, so a glibc 2.3 sysroot would not help.

Even if we had CentOS sysroot linkage model in place today he would at
most have saved himself the work of building a new sysroot, but his
applications would still fail because the kernel is too old to provide
the features the application expects without checking.

What did I miss?

-- 
Cheers,
Carlos.