Eric Blake wrote:
> [adding bug-gnulib]
>
> On 05/25/2011 03:29 PM, Eric Blake wrote:
>>>> building coreutils-8.12 with '--enable-gcc-warnings' fails on my
>>>> SLES 10.3 server:
>>>>
>>>> CC uinttostr.o
>>>> cc1: warnings being treated as errors
>>>> In file included from uinttostr.c:3:
>>>> anytostr.c: In function 'uinttostr':
>>>> anytostr.c:39: warning: comparison of unsigned expression < 0 is always
>>>> false
>>>
>>> the warning is spurious. But we don't know how
>>> to shut up gcc.
>>
>> You're not the first to hit this, either:
>>
>> http://lists.gnu.org/archive/html/bug-gnulib/2010-10/msg00435.html
>>
>> Since our party line back then was to "upgrade gcc or quit using -Werror
>> with old gcc", I'm marking this as a wontfix; but if you can come up
>> with a patch, we can reopen it.
>
> Jim, Paul,
>
> This patch silences the gcc warning even for gcc too old to honor the
> pragma, but I can't help but feel that it might be too gross (it makes
> functions like uinttostr larger in size). What do you think?
Hi Eric,
Thanks for investigating, but
SLES 10.3's gcc is too old for --enable-gcc-warnings.
Coreutils' documentation (this originated as a report against
coreutils) is clear that you should use the --enable-gcc-warnings
option only with a "very recent version of gcc":
[from README-hacking]
[*] The --enable-gcc-warnings option is useful only with glibc
and with a very recent version of gcc. You'll probably also have
to use recent system headers. If you configure with this option,
and spot a problem, please be sure to send the report to the bug
reporting address of this package, and not to that of gnulib, even
if the problem seems to originate in a gnulib-provided file.
The solution is not to enable those warnings on anything but
"new enough" gcc+glibc.
I've closed the coreutils ticket.
