sizeof size_t != sizeof unsigned long

[Nicolas Goutte]

>List:       kde-core-devel
>Subject:    Re: sizeof size_t != sizeof unsigned long
> From:       Dirk Mueller <mueller () kde ! org>
>Date:       2004-02-22 17:42:00
>Message-ID: <200402221842.00534.mueller () kde ! org>
>
>On Sunday 22 February 2004 18:07, Nicolas Goutte wrote:
>
>> The check "sizeof size_t == sizeof unsigned long" fails (since at least
>> Summer 2003) for RH 7.3 systems
>

>No, it doesn't. This was a single case of a miserably broken system. The
>problem was that we checked for support of -Wformat related warnings in $CXX,
>but $CC was pointing to a different, older compiler (older than gcc 2.95). 

I am sorry, but that is not what config.log tells:

configure:2585: checking for C compiler version
configure:2588: cc --version </dev/null >&5
2.96
configure:2591: $? = 0
configure:2593: cc -v </dev/null >&5
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)


So we are talking about gcc 2.96, not about kcc or egcs 1.2 (or whatever to 
call it.)

>Therefore, the -Wformat check passed, we added the flags, and when we ran 

There is no -Wformat check, at least I could not find any. And if such a 
-Wformat check failed, then no test with -Wformat variants should be tried at 
all.

Also I do not understand why -Wformat is not used at all, as the gcc 3.3.1 
info page tells that it is needed for having any of its variants work. (So it 
will work when -Wall is used but the behaviour will be undefined if -Wall is 
not used.)

Also I cannot find any test where
 -Wformat-security -Wmissing-format-attribute
are tested together, which would fail and where we could react. The tests are 
always for something else.

>$CC, all $CC based tests failed. It is pure luck that this error message

Sure, it could be any error message. 

>appeared, it could have been any other too. A real bug might be that it 
>prefers "cc" over "gcc", which it should never do. However, the Redhat 7.3 
>reporter didn't seem to be interested in tracing this problem down, so we
>have to wait till it happens again, since I cannot reproduce it. A preferable 
>workaround would have been to disable --enable-warnings in the release
>tarballs. 

Well, sorry, looking at the config.log file I can see enough things to try to 
react. (But perhaps I am too much used to file formats documents where you 
have to read between the lines.)

>
>I'm not sure if it is a wise idea to check for such a severly broken system, 
>since usually it is okay to compile C code with a different compiler than the
>C++ code (the usual case when using KCC). 

But we are not talking about KCC.

Also RH means North-American market, India etc. Do you want to lose these 
markets by not trying to support gcc 2.96?

How many of the reporters of the bug are not using KDE because they could not 
compile it? How many of them are spreading bad press on KDE?

And no, I am not asking for over-human effort to support it. I am just asking 
little steps toward a possible solution. Then at the next KDE 3.2.x, we could 
see if we still get RH users having problems.

>
>> and now it seems that it breaks for gcc 
>> 2.95 systems too.
>
>No, it doesn't. Plenty of KDE developers use 2.95, and gcc 2.95 supports the
>-Wformat attributes just fine (much unlike the broken redhat-gcc, which has a
>higher version number than 2.95, but actually supports less features).

But -Wformat itself is not used. It might work for some gcc 2.95, but it is 
not what is documented for gcc (and I mean documented for gcc 3.3.1.)

>
>Again, without config.log its hard to say what goes wrong, but I guess here 
is 
>again a case of "cc" pointing to a severly broken compiler.

Well, for me the log tells to try to use -Wformat explicitely and also to 
check for
 -Wformat-security -Wmissing-format-attribute
and not using -Wmissing-format-attribute if it fails. 

I think that it should bring us further.

>
>
>Dirk

Have a nice day!

>