This is the mail archive of the
mailing list for the glibc project.
Re: build glibc without support for utimensat/futimens and epoll?
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
You have one of two options for that rebuild:
(a) Using the existing CentOS 5 system tools.
(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?