Glibc 2.20 released
| From: | Allan McRae <allan-AT-archlinux.org> | |
| To: | libc-alpha <libc-alpha-AT-sourceware.org>, libc-announce-AT-sourceware.org, info-gnu-AT-gnu.org | |
| Subject: | The GNU C Library version 2.20 is now available | |
| Date: | Mon, 08 Sep 2014 07:46:18 +1000 | |
| Message-ID: | <540CD22A.7070202@archlinux.org> | |
| Archive‑link: | Article |
The GNU C Library ================= The GNU C Library version 2.20 is now available. The GNU C Library is used as *the* C library in the GNU systems and is widely used on systems with the Linux kernel. The GNU C Library is primarily designed to be a portable and high performance C library. It follows all relevant standards including ISO C11 and POSIX.1-2008. It is also internationalized and has one of the most complete internationalization interfaces known. The GNU C Library webpage is at http://www.gnu.org/software/libc/ Packages for the 2.20 release may be downloaded from: http://ftpmirror.gnu.org/libc/ http://ftp.gnu.org/gnu/libc/ The mirror list is at http://www.gnu.org/order/ftp.html NEWS for version 2.20 ==================== * The following bugs are resolved with this release: 6804, 9894, 12994, 13347, 13651, 14308, 14770, 15119, 15132, 15347, 15514, 15698, 15804, 15894, 15946, 16002, 16064, 16095, 16194, 16198, 16275, 16284, 16287, 16315, 16348, 16349, 16354, 16357, 16362, 16447, 16516, 16532, 16539, 16545, 16561, 16562, 16564, 16574, 16599, 16600, 16609, 16610, 16611, 16613, 16619, 16623, 16629, 16632, 16634, 16639, 16642, 16648, 16649, 16670, 16674, 16677, 16680, 16681, 16683, 16689, 16695, 16701, 16706, 16707, 16712, 16713, 16714, 16724, 16731, 16739, 16740, 16743, 16754, 16758, 16759, 16760, 16770, 16786, 16789, 16791, 16796, 16799, 16800, 16815, 16823, 16824, 16831, 16838, 16839, 16849, 16854, 16876, 16877, 16878, 16882, 16885, 16888, 16890, 16892, 16912, 16915, 16916, 16917, 16918, 16922, 16927, 16928, 16932, 16943, 16958, 16965, 16966, 16967, 16977, 16978, 16984, 16990, 16996, 17009, 17022, 17031, 17042, 17048, 17050, 17058, 17061, 17062, 17069, 17075, 17078, 17079, 17084, 17086, 17088, 17092, 17097, 17125, 17135, 17137, 17150, 17153, 17187, 17213, 17259, 17261, 17262, 17263, 17319, 17325, 17354. * Reverted change of ABI data structures for s390 and s390x: On s390 and s390x the size of struct ucontext and jmp_buf was increased in 2.19. This change is reverted in 2.20. The introduced 2.19 symbol versions of getcontext, setjmp, _setjmp, __sigsetjmp, longjmp, _longjmp, siglongjmp are preserved pointing straight to the same implementation as the old ones. Given that, new callers will simply provide a too-big buffer to these functions. Any applications/libraries out there that embed jmp_buf or ucontext_t in an ABI-relevant data structure that have already been rebuilt against 2.19 headers will have to rebuilt again. This is necessary in any case to revert the breakage in their ABI caused by the glibc change. * Support for file description locks is added to systems running the Linux kernel. The standard file locking interfaces are extended to operate on file descriptions, not file descriptors, via the use of F_OFD_GETLK, F_OFD_SETLK, and F_OFD_SETLKW. File description locks are associated with an open file instead of a process. * Optimized strchr implementation for AArch64. Contributed by ARM Ltd. * The minimum Linux kernel version that this version of the GNU C Library can be used with is 2.6.32. * Running the testsuite no longer terminates as soon as a test fails. Instead, a file tests.sum (xtests.sum from "make xcheck") is generated, with PASS or FAIL lines for individual tests. A summary of the results is printed, including a list of failing lists, and "make check" exits with error status if there were any unexpected failures. "make check stop-on-test-failure=y" may be used to keep the old behavior. * The am33 port, which had not worked for several years, has been removed from ports. * The _BSD_SOURCE and _SVID_SOURCE feature test macros are no longer supported; they now act the same as _DEFAULT_SOURCE (but generate a warning). Except for cases where _BSD_SOURCE enabled BSD interfaces that conflicted with POSIX (support for which was removed in 2.19), the interfaces those macros enabled remain available when compiling with _GNU_SOURCE defined, with _DEFAULT_SOURCE defined, or without any feature test macros defined. * Optimized strcmp implementation for ARMv7. Contributed by ARM Ltd. * Added support for TX lock elision of pthread mutexes on s390 and s390x. This may improve lock scaling of existing programs on TX capable systems. The lock elision code is only built with --enable-lock-elision=yes and then requires a GCC version supporting the TX builtins. With lock elision default mutexes are elided via __builtin_tbegin, if the cpu supports transactions. By default lock elision is not enabled and the elision code is not built. * CVE-2014-4043 The posix_spawn_file_actions_addopen implementation did not copy the path argument. This allowed programs to cause posix_spawn to deference a dangling pointer, or use an unexpected pathname argument if the string was modified after the posix_spawn_file_actions_addopen invocation. * All supported architectures now use the main glibc sysdeps directory instead of some being in a separate "ports" directory (which was distributed separately before glibc 2.17). * The NPTL implementation of POSIX pthreads is no longer an "add-on". On configurations that support it (all Linux configurations), it's now used regardless of the --enable-add-ons switch to configure. It is no longer possible to build such configurations without pthreads support. * Locale names, including those obtained from environment variables (LANG and the LC_* variables), are more tightly checked for proper syntax. setlocale will now fail (with EINVAL) for locale names that are overly long, contain slashes without starting with a slash, or contain ".." path components. (CVE-2014-0475) Previously, some valid locale names were silently replaced with the "C" locale when running in AT_SECURE mode (e.g., in a SUID program). This is no longer necessary because of the additional checks. * On x86-64, the dynamic linker's lazy-binding support is now compatible with application code using Intel MPX instructions. (With all previous versions, the MPX register state could be clobbered when making calls into or out of a shared library.) Note that while the new dynamic linker is compatible with all known x86 hardware whether or not it supports Intel MPX, some x86 instruction-set emulators might fail to handle the new instruction encodings. This is known to affect Valgrind versions up through 3.9 (but will be fixed in the forthcoming 3.10 release), and might affect other tools that do instruction emulation. * Support for loadable gconv transliteration modules has been removed. The support for transliteration modules has been non-functional for over a decade, and the removal is prompted by security defects. The normal gconv conversion modules are still supported. Transliteration with //TRANSLIT is still possible, and the //IGNORE specifier continues to be supported. (CVE-2014-5119) * Decoding a crafted input sequence in the character sets IBM933, IBM935, IBM937, IBM939, IBM1364 could result in an out-of-bounds array read, resulting a denial-of-service security vulnerability in applications which use functions related to iconv. (CVE-2014-6040) Contributors ============ This release was made possible by the contributions of many people. The maintainers are grateful to everyone who has contributed changes or bug reports. These include: Adam Conrad Adhemerval Zanella Alan Modra Allan McRae Andi Kleen Andreas Krebbel Andreas Schwab Arjun Shankar Aurelien Jarno Bernard Ogden Carlos O'Donell Chris Metcalf David Holsgrove David S. Miller David Svoboda Dominik Vogt Dylan Alex Simon Eric Wong Florian Weimer Guo Yixuan H.J. Lu Ian Bolton Igor Zamyatin Jeff Layton Jim Meyering Joey Ye Jose E. Marchesi Joseph Anthony Pasquale Holsten Joseph Myers Julian Brown Khem Raj Konstantin Serebryany Kyle McMartin Ling Ma Ludovic Courtès Maciej W. Rozycki Marcus Shawcroft Mark Wielaard Marko Myllynen Meador Inge Mike Frysinger Ondřej Bílka Paul Eggert Paul Pluzhnikov Peter TB Brett Rajalakshmi Srinivasaraghavan Rasmus Villemoes Richard Earnshaw Richard Henderson Roland McGrath Sami Kerola Samuel Thibault Sean Anderson Serge Hallyn Siddhesh Poyarekar Sihai Yao Stefan Liebler Steve Ellcey Tomas Dohnalek Torvald Riegel Venkataramanan Kumar Vidya Ranganathan Wilco Wilco Dijkstra Will Newton Yang Yingliang Yufeng Zhang Yury Gribov Yvan Roux
Posted Sep 8, 2014 13:43 UTC (Mon)
by josh (subscriber, #17465)
[Link]
And there was much rejoicing.
Posted Sep 8, 2014 13:54 UTC (Mon)
by jch (guest, #51929)
[Link] (12 responses)
It only took some 30 years to get usable POSIX locks.
Posted Sep 8, 2014 14:51 UTC (Mon)
by geertj (guest, #4116)
[Link] (9 responses)
Anybody knows if the per-fd file range locks support NFS?
I remember that the traditional BSD per-fd locks do not always support it and that was a reason to use the broken, per-process locks.
If NFS is indeed supported, then I agree, after 30 years we get usable file locks :)
Posted Sep 8, 2014 15:30 UTC (Mon)
by josh (subscriber, #17465)
[Link] (8 responses)
I would tend to phrase that as "if NFS supports the per-fd file range locks".
I've seen some discussion about NFS and the new locks, but no obvious signs of support.
Posted Sep 8, 2014 18:31 UTC (Mon)
by bfields (subscriber, #19510)
[Link]
Looks to me like it should just work, though.
Posted Sep 8, 2014 19:39 UTC (Mon)
by luto (guest, #39314)
[Link] (6 responses)
(Minor nit: these aren't per-fd locks; they're per-open-file-description locks. This makes a big difference if dup or SCM_RIGHTS is used. Or, for that matter, if fork copies a non-CLOEXEC fd.)
Posted Sep 9, 2014 9:03 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (2 responses)
Nix said it's fine so long as you've got a pure linux setup. Anything else, and you're into a world of hurt where things work locally but not over NFS, or over NFS but not locally, or they appear locked when they aren't, or or or.
And it's easy to prove, from the spec, that such behaviour is "as designed" :-(
Cheers,
Posted Sep 9, 2014 14:16 UTC (Tue)
by bfields (subscriber, #19510)
[Link] (1 responses)
That's not quite right, and not what Nix said.
The problem discussed there is the handling of POSIX (fcntl) and BSD (flock) locks. They do not normally interact with each other, except on NFS, where these days the Linux client translates both into the same kind of NFS lock (because that's the only kind NFS has available).
That behavior is identical whether you're using a Linux server or something else.
Posted Sep 17, 2014 18:25 UTC (Wed)
by nix (subscriber, #2304)
[Link]
(Still haven't had a problem that's affected real life -- this was just test code -- but still, thanks, Lennart, I'd have spent ages hunting for the cause of *that* one if it hadn't been for our recent discussion! :) )
Posted Sep 9, 2014 14:02 UTC (Tue)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Sep 9, 2014 14:24 UTC (Tue)
by bfields (subscriber, #19510)
[Link] (1 responses)
I don't see a problem.
The POSIX/BSD problem arises because the two types of locks don't normally conflict with each other, but are forced to on NFS because they must be represented as the same type of lock.
But POSIX and the new open file description locks *do* conflict with each other (see a recent copy of the fcntl(2) man page), so it's simple enough to represent both over the same lock protocol.
Note that NFS locking is POSIX-like (in particular, it supports byte ranges), so it's BSD locks that would need to be added.
Posted Sep 17, 2014 18:26 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Sep 8, 2014 22:34 UTC (Mon)
by wahern (subscriber, #37304)
[Link]
The ability to query the PID of the owner is one reason why the lock can't be inherited across fork.
Posted Sep 8, 2014 23:14 UTC (Mon)
by neilbrown (subscriber, #359)
[Link]
I prefer to think that it only took "1 person" to get usable POSIX locks. The rest of us were ... not part of the solution.
Thanks Jeff!!
Glibc 2.20 released
Glibc 2.20 released
Glibc 2.20 released
Glibc 2.20 released
Glibc 2.20 released
Glibc 2.20 released
Glibc 2.20 released
Wol
Glibc 2.20 released
Nix said it's fine so long as you've got a pure linux setup. Anything else, and you're into a world of hurt where things work locally but not over NFS, or over NFS but not locally, or they appear locked when they aren't, or or or.
Glibc 2.20 released
Glibc 2.20 released
Glibc 2.20 released
Well, it's a new kind of lock. You don't want this sort of lock on the client side to turn into the old form of POSIX lock on the server end, or vice versa.
So the protocol will need updating. (Since it needs updating to understand that POSIX locks exist at all, why not do both at once! :) )
Glibc 2.20 released
But POSIX and the new open file description locks *do* conflict with each other (see a recent copy of the fcntl(2) man page), so it's simple enough to represent both over the same lock protocol.
True. I don't know what I was thinking. (Of couse, they'll still wrongly conflict with fnctl() locks...)
Glibc 2.20 released
Glibc 2.20 released