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!
nice post. thanks
Hi Diego,is it any safe to set -D_GNU_SOURCE globally in cflags and cxxflags when using gcc-4.3.1 and glibc-2.7 ?many thanks in advance
Nope it’s not safe. You can find a good example in @sys-block/iscsitarget@: it doesn’t build out of the tarball with glibc 2.8 because it lacks @_GNU_SOURCE@ definition, but it will fail if you add it. Why? Because it has redefinitions of names that are present in glibc with the GNU extensions.@_GNU_SOURCE@ should be defined on a per-project basis. It’s actually defined by most projects already because it enables functions like @asprintf()@, but there are still some who don’t enable it or don’t enable it with uniformity between units.
ah, ok, thanks for clearing that :)concerning gcc-4.3 caused errors: for the sake of completeness O_CREAT is another one (triggered by -D_FORTIFY_SOURCE=2)gcc-4.3 hardened also doesn’t seem to play fine with glibc-2.8more info on that:http://forums.gentoo.org/vi…and:https://hardened.gentooexpe…
In order to compileconsolekit, I had to add the -D_GNU_SOURCE to cflags, I hope they fix it before I have to do this again because there is no way to record the new cflags anywhere like a use flag.Thanks a lot for this.