Mike already wrote to gentoo-dev about the new build failures with glibc 2.8. Thanks GNU, really, for starting the long overdue cleanup.
I say long overdue because other C libraries like FreeBSD’s and others already had headers that included the very minimum needed. So some of the issues that we’re going to fix now were just as valid for FreeBSD and others.
So this is going to help portability to FreeBSD and viceversa, stuff already ported to FreeBSD should build just fine with the new glibc version.
As I’m borderline masochist, I started looking at patches to see if I can easily tell if they are good and commit them myself as needed (yeah I know I step over lots of toes; with most people I got agreements before though, so sometimes it’s just fine, beside as long as the patch works and I don’t break stuff nobody complained recently 😉 ).
One thing I noticed was a misfiled bug, it reported failure with glibc 2.8 when it was instead a failure with gcc 4.3. The issue is more or less the same, missing includes most of the time, because both projects cleaned up their header files, but it’s important to know which package caused it to make sure that the faulty ebuild are all stable before gcc and glibc can make stable.
For the list of bugs caused by glibc 2.8 I refer you to the tracker; as you can see there, the usual problems are:
- PATH_MAX undeclared;
- ARG_MAX undeclared;
- field ‘reg’ has incomplete type;
- storage size of ‘peercred’ isn’t known.
The solution for some of these issues is to add the right include (like limits.h), for others is to properly define _GNU_SOURCE to get the GNU extensions enabled. Usually projects using autotools already have a check for that, but recent autoconf versions use config.h to define that, and not all the sources include it.
On ebuilds you can work that around by using append-flags -D_GNU_SOURCE but upstream should fix their source files by including config.h right at the start of every source file.
For failures related to C++ code, like undeclared ostream or cerr, the problem is not with glibc 2.8 but with gcc 4.3 instead.
Enjoy!