aboutsummaryrefslogtreecommitdiff
path: root/NEWS
diff options
context:
space:
mode:
authorFlorian Weimer <fweimer@redhat.com>2019-02-08 10:21:56 +0100
committerFlorian Weimer <fweimer@redhat.com>2019-02-08 10:43:17 +0100
commitf289e656ec8221756519a601042bc9fbe1b310fb (patch)
treed0a6ca2140f0e4a0fa34fd10ee0b0c03266fb196 /NEWS
parent823624bdc47f1f80109c9c52dee7939b9386d708 (diff)
downloadglibc-f289e656ec8221756519a601042bc9fbe1b310fb.zip
glibc-f289e656ec8221756519a601042bc9fbe1b310fb.tar.gz
glibc-f289e656ec8221756519a601042bc9fbe1b310fb.tar.bz2
rt: Turn forwards from librt to libc into compat symbols [BZ #24194]
As the result of commit 6e6249d0b461b952d0f544792372663feb6d792a ("BZ#14743: Move clock_* symbols from librt to libc."), in glibc 2.17, clock_gettime, clock_getres, clock_settime, clock_getcpuclockid, clock_nanosleep were added to libc, and the file rt/clock-compat.c was added with forwarders to the actual implementations in libc. These forwarders were wrapped in #if SHLIB_COMPAT (librt, GLIBC_2_2, GLIBC_2_17) so that they are not present for newer architectures (such as powerpc64le) with a 2.17 or later ABI baseline. But the forwarders were not marked as compatibility symbols. As a result, on older architectures, historic configure checks such as AC_CHECK_LIB(rt, clock_gettime) still cause linking against librt, even though this is completely unnecessary. It also creates a needless porting hazard because architectures behave differently when it comes to symbol availability. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Diffstat (limited to 'NEWS')
-rw-r--r--NEWS6
1 files changed, 5 insertions, 1 deletions
diff --git a/NEWS b/NEWS
index e14008d..45792f6 100644
--- a/NEWS
+++ b/NEWS
@@ -14,7 +14,11 @@ Major new features:
Deprecated and removed features, and other changes affecting compatibility:
- [Add deprecations, removals and changes affecting compatibility here]
+* The functions clock_gettime, clock_getres, clock_settime,
+ clock_getcpuclockid, clock_nanosleep were removed from the librt library
+ for new applications (on architectures which had them). Instead, the
+ definitions in libc will be used automatically, which have been available
+ since glibc 2.17.
Changes to build and runtime requirements: