Created attachment 299415 [details] Config.log Greetings, attempting to perform a glibc update from 2.12.2 to 2.13-r4, but it failed: during GLIBC configuration for nptl, it stopped when checking "C cleanup handling" because "compiler must support it" GCC version is 4.5.3-r1. I'm aware of the Bug ID '392461', but i would like to know if i could help fixing it, or provide further information to
Created attachment 299419 [details] Emerge info
Created attachment 299425 [details] Build log
I've opened this issue over the forum: http://forums.gentoo.org/viewtopic-t-908292-highlight-.html and Hu's analysis result was: This appears to be a bug in the configure script. They assume that they can pass -Werror, but they use code which causes a warning, which then becomes fatal when they add -Werror. sames as bug ID '392461', so my concern is if i could help in some way for the confgure script Greetings
cc1: warnings being treated as errors conftest.c: In function 'cl': conftest.c:44:16: error: unused parameter 'a' CFLAGS="...-Wall -Wextra" so sort of INVALID. Hu missed a point: '-Werror' was there on purpose, as otherwise the check wouldn't have worked - gcc would only generate a warning.
are -Wall -Wextra unusable only for glibc or many others? if latter: as long as per-package Cflags is not suggested, how can i use them for debugging porpouses? (or they are the unique exception for cflag-per-package-usage ?) THanks, Matias
From Hu: The upstream check for the attribute requires using -Werror, but there is no reason for them to include an unused parameter in their implementation of cl. That unused parameter will generate a warning when compiled with -Wall -Wextra. Their code should leave the parameter anonymous, cast it to void, or use some other construct to ensure that the parameter is not considered unused.
Well, the point is made in the comment of this commit (http://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=54c726aa5c0414148d03059c1bce14baaa0c7c09). "...It's unwise to use GCC that way, but apparently enough people do it nowadays that it's an issue...."
*** This bug has been marked as a duplicate of bug 392461 ***