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

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

On 03/23/2018 03:35 PM, Ben Sferrazza wrote:
> Several of our Linux servers at work are running an old distribution
> (CentOS 5) with kernel 2.6.18. We supposedly are running these to support
> some CAD software and these cannot be upgraded, nor do I have root access
> anyways.
> 
> To work around this I have built an insulated toolchain+libraries+binaries
> environment in a non-standard and non-root directory (/home/tools), that
> uses the latest glibc, 2.19, that supports kernel 2.6.18. I did use the
> lastest Linux kernel headers, 4.15.12. Everything has worked pretty well,
> but I'd like to re-build everything, applying the things I've learned along
> the way.
> 
> One of those things was that when I built Perl and Python 3, they
> determined that Linux server supports the nanosecond time functions,
> utimensat and futimens. I'm not sure if it's because of the old kernel
> 2.6.18 or the filesystem, but the Linux server does not support nanosecond
> time stamping. To get around this, I had to use ac_cv_fun_utimensat=no and
> ac_cv_func_futimens=no when building Python 3 for instance. Is there a way
> I can tell glibc not to enable these fuctions when building, so when
> building other binaries they properly detect that this is not supported?
> 
> Similarly, I had a problem with Xorg during runtime issuing an
> epoll.create() syscall and receiving a '-1 ENOSYS' in response. I'm more
> surprised that glibc didn't automatically detect this when it was built. I
> had to rebuild Xorg and explicitly tell it not to build with epoll support.
> Similarly, can I not tell glibc to avoid building epoll support?

You cannot remove functions from glibc, they are part of the ABI and API.

With each release you will get new functions added, and others deprecated
as part of the development process, but you have no explicit control over
this because of the complexity involved in maintaining backwards compatibility.

Applications should be written such that they can handle if a function does
not work at runtime, but often they are not.

-- 
Cheers,
Carlos.