build glibc without support for utimensat/futimens and epoll?

[Carlos O'Donell]

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?

You are right in that to solve Ben's problem in Fedora we might have provided
some kind of "Old glibc" that Ben could link against. Such a glibc would have
"removed functions" from perspective of the present glibc.

Does that match what you were thinking?

> Ben, you could patch glibc to remove the functions from the installed header files, and turn them into compat symbols.  Then application configure checks will not be able to see this functions, but your glibc will still be ABI-compatible with any glibc of the same version.

Right, I tried to make my answer to Ben as black and white as I could,
that there really wasn't a "flag" you could flip to disable particular
APIs.

> If that's too much work, you need to build an older glibc instead.

Right.

-- 
Cheers,
Carlos.