This is the mail archive of the
mailing list for the glibc project.
build glibc without support for utimensat/futimens and epoll?
- From: Ben Sferrazza <bsferrazza at avnera dot com>
- To: libc-help at sourceware dot org
- Date: Fri, 23 Mar 2018 13:35:22 -0700
- Subject: build glibc without support for utimensat/futimens and epoll?
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
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
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?
Thank you for your help!