This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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:, 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]