Development

A GNU C Library update

A traditional feature of the tools track at the Linux Foundation's Collaboration Summit is an update from the developers of the GNU C Library (glibc); that tradition was upheld in fine form at the 2015 event. Glibc developer Roland McGrath noted that while the project is a critical component in vast numbers of Linux installations, it does not have a lot of developers working on it. Still, even with a relatively small developer base, some real progress has been made over the last year.

Recent history

The glibc 2.20 release came out last August featuring contributions from 69 developers. This release fixed 160 bugs, four of which had CVE numbers attached to them. It added support for Intel's MPX memory protection mechanism to the dynamic loader; that support is not useful for much now, but it will be a useful preparation once MPX-enabled applications appear in the future. Lock elision support has been added for the s390 architecture. There are new, optimized string functions for the ARMv7 and ARM64 subarchitectures, while support for the ancient AM33 subarchitecture has been removed.

Also in 2.20, the _BSD_SOURCE and _SVID_SOURCE feature test macros have been removed. The declarations formerly available under those macros are now under _DEFAULT_SOURCE, but, since it's the default, one need not set it explicitly. Roland's suggestion, though, was that most code would (continue to) want to use _GNU_SOURCE or one of the POSIX-specific macros. (See this article for an introduction to glibc feature test macros).

Support for file-private POSIX locks has been added to this release. And, finally, as of 2.20, the oldest supported kernel release is 2.6.32. Users staying with older kernels are, most likely, not going to update their C library either.

Glibc 2.21 was released on February 6. It had changes from 61 developers, fixing 101 bugs and five security issues. The MIPS architecture has gained support for the O32 FPXX, FP64, and FP64A ABIs. Support for the obsolete sigvec() functions has been removed (though ABI support remains for older binaries). The sigvec() ABI dates back to the 4.2 BSD release and, Roland said, was replaced by sigaction() 25 years ago.

The 2.21 release includes support for a handful of new locales. The i386 memcpy() implementation has been optimized. The PowerPC architecture has gained support for lock elision and optimized string functions as well. Various architecture-specific semaphore implementations have been replaced by a single generic version written in C; that should help the developers to maintain this code and avoid introducing race conditions in the future. Also in this release is support for Altera's NIOS II architecture.

The 2.22 release cycle has just gotten underway; as of Roland's talk it had five bugfixes but not much else. He expects to see a rework of the POSIX thread cancellation code to fix some race conditions there. The process of cleaning up the atomic-operation and futex code will continue as well; it is part of a long-term project to move the library toward the C11 memory model. Once that is done, he said, the developers should be able to have a higher level of confidence in the correctness of the library's synchronization code.

Glibc in the next five years

Looking forward, Roland said that, five years from now, the glibc developers will have put out ten releases and, probably, have fixed about 1,500 bugs. But it would be nice if the project could accelerate a bit, bringing in more useful features while maintaining the quality of the code. To do that, though, the developers need some more help.

One place where interested people could contribute is in bug triage. It takes a lot of work to go through the bug tracker, assign priorities to bugs, determine whether they might have security relevance, create minimal programs to reproduce bugs, and, even, write patches to fix them. Another area where help is needed is with benchmarks; what is there now is not really adequate to judge the value of performance patches. Benchmarks for the math library are especially needed. Microbenchmarks are valuable, but there is also a need for whole-system benchmarks that can be used for workload-specific tuning. Writing benchmarks, Roland said, is a great way to develop a working knowledge of the API.

Then, there is the matter of testing infrastructure. Glibc is, by its nature, a conservative project that puts a premium on not breaking things. Often the biggest blocker for new patches is the simple lack of adequate testing; a good automated testing framework would help the project to merge new code more quickly. The problem is not an easy one, though, he said.

Among other things, the project needs test suites that can run against an installed version of the library. Otherwise it can be hard to test the resolver and other parts of the library that interact with the rest of the system and the network. Some of the more complex tests probably need to be run within containers. Also needed is ABI comparison testing; the project has some "superficial" tests now that look at symbols, versions, and the size of data objects, but there's no testing for ABI breakage beyond that. The libabigail library out of the GCC project should probably be brought in to help with this task.

Finally, the developers could use help supporting the project's infrastructure — the wiki, bug tracker, build systems, etc. Interested people should consult the project's master "todo" list for lots more information.

An audience member asked about the handling of security bugs. Roland answered that the project Bugzilla includes a flag to mark whether any particular bug has been reviewed for security implications. The project could use some help with that kind of review, he said. One of the recent CVE entries for glibc referred to a bug that had been fixed in 2013, but nobody had realized at the time that it was exploitable. It would be nice to catch more of those, but, Roland said, the primary responsibility for identifying and responding to security bugs lies downstream with the distributors.

Another attendee asked about EGLIBC. Roland said that he's not really the right person to talk about that project but that, as far as he can tell, it has mostly gone away. Some of the developers behind the EGLIBC fork are now core glibc developers, and most (but not all) of the EGLIBC changes have been pulled back into glibc. In general, Roland would like to see all of the glibc forks out there merge back into the mainline. But, while distributors have patches that they apply, he is not aware of any distributors shipping forks at this point.

The next question had to do with contributor-agreement process that developers must go through to get code accepted; it was described as being complicated and an obstacle to contribution. Roland agreed with that assessment, but said that the legal aspects were outside of the project's control. Glibc is a GNU project; that fact is not going to change. It would be nice if the agreement process could be streamlined, but it is up to the GNU project to do that.

The last question had to do with support for building the library with the LLVM compiler. It was noted that there has been pushback against the merging of LLVM support into some GNU projects; would there be difficulties in getting LLVM support into glibc? Roland answered that he didn't see any reason for there to be trouble. In general, the glibc developers have been working toward the use of more standard language features and getting away from GCC extensions. That is a technical goal aimed at making the glibc code better. Technical improvement is where the glibc project's interests lie; the glibc developers, he said, are uninterested in the political issues.

[Your editor would like to thank the Linux Foundation for supporting his travel to the Collaboration Summit.]

Comments (48 posted)

Quotes of the week

— Christian Hergert, laying down some harsh truths at SCALE 13x.

— Jon Cruz at SCALE 13x, reflecting on the power of Emacs.

Comments (none posted)

Astropy v1.0 released

Version 1.0 of the Astropy Python library has been released. Astropy is the core Python package for Astronomy development. Highlights of the 1.0 release include new sub-packages for visualization and for analytical functions, support for Altitude/Azimuth and Galactocentric coordinate systems, and significant speedups when reading and writing ASCII files, thanks to a C-based IO subsystem.

Full Story (comments: none)

GDB 7.9 released

Version 7.9 of the GDB debugger is out. Changes include enhancements to the Python scripting API, the ability to compile and inject code into the debugged program, signal-handling improvements, and more.

Full Story (comments: none)

GNOME 3.15.90

The first beta in the GNOME 3.15 development series has been released. GNOME 3.15.90 features a new GNOME shell theme, redesigned notifications in GNOME shell, codec installation integrated in gnome-software, a login screen on Wayland, and more.

Full Story (comments: 48)

Firefox 36 released

Mozilla has released Firefox 36.0. The release notes mention a few new features, including support for the full HTTP/2 protocol. This version will no longer accept insecure RC4 ciphers whenever possible and certificates with 1024-bit RSA keys will be phased out. See the release notes for more information.

Comments (48 posted)

Development newsletters from the past week

• What's cooking in git.git (February 19)
• What's cooking in git.git (February 22)
• LLVM Weekly (February 23)
• OCaml Weekly News (February 24)
• OpenStack Community Weekly Newsletter (February 20)
• Perl Weekly (February 23)
• PostgreSQL Weekly News (February 22)
• Python Weekly (February 19)
• Ruby Weekly (February 19)
• This Week in Rust (February 23)
• Qt Weekly (February 23)
• Tor Weekly News (February 25)
• Wikimedia Tech News (February 23)

Comments (none posted)

Morevna Production Report #1

The Beautiful Queen Marya Morevna is a Russian folk tale. The Morevna Project makes anime videos about Morevna, using free software. This progress report covers the status of their newest episode. "Our main animation tool is Synfig Studio and for the past years it was improved a lot. I guess it’s needles to say, that the new episode will be produced using the latest development version of Synfig. For current stage of the project it is important to ensure that the tool is stable enough for production, so last weeks we were concentrated on fixing the critical bugs. As result of this work, we have published the first Release Candidate for the new stable version of Synfig Studio, which is going to be numbered as 1.0 by the way." (Thanks to Paul Wise)

Comments (7 posted)