Bug? report for trunk

[santi]

Make failed for the latest trunk last night:

......
astarsearch.cpp:176: instantiated from here
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:208: warning·: comparison between signed and unsigned integer expressions
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:212: warning·: comparison between signed and unsigned integer expressions
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:216: warning·: comparison between signed and unsigned integer expressions
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:220: warning·: comparison between signed and unsigned integer expressions
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:228: warning: comparison between signed and unsigned integer expressions
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:232: warning·: comparison between signed and unsigned integer expressions
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:236: warning·: comparison between signed and unsigned integer expressions
make[2]: *** [astarsearch.o] Error 1
make[2]: Leaving directory `/home/me/trunk/trunk/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/me/trunk/trunk'
make: *** [all] Error 2

Something wrong with trunk?

[loonycyborg]

Actually, those are warnings. You can make them non-fatal with ./configure --disable-strict-compilation. After -Wno-sign-compare option was dropped, you'll have to always use --disable-strict-compilation if you use gcc 4.1.2 since its headers trigger that warning.

[silene]

since its headers trigger that warning.

What I don't understand is why -Wno-system-headers doesn't work for you. Was this option broken or missing in gcc 4.1.2?

[santi]

Actually, those are warnings

A warning triggering a fatal error should not be a warning. So it's a gcc issue?

[silene]

A warning triggering a fatal error should not be a warning. So it's a gcc issue?

No, the fatal error is not a GCC issue, it is on purpose: Wesnoth is explicitly compiled with option -Werror, which forbids any warning.

[santi]

So just follow loonycyborg's suggestion to compile with the right options and everything should work fine. Maybe this should be announced more widely to prevent such issues

[appleide]

Okay it's been a couple of months... but I'm really curious. Why are warnings allowed into the Wesnoth source code? In uni we're taught to try to eliminate as many warnings as possible, yet that doesn't seem to be what you guys are doing with Wesnoth.

[Max]

because different toolchains produce different warnings...

[AI]

Exactly. Many of us compile with -Werror or equivalents, but some compilers are more pedantic than others. (especially MSVC is known to barf at random things)

[Max]

not sure if msvc is to blame here. it's just that bfw is most of the times compiled with gcc. i've ported a project that was initially created with vs to linux and mac and it's been the same thing - lot's of (partially strange) warnings.

would be nice if trunk would be compiled with several buildchains before a release is tagged...

[SkeletonCrew]

Okay it's been a couple of months... but I'm really curious. Why are warnings allowed into the Wesnoth source code? In uni we're taught to try to eliminate as many warnings as possible, yet that doesn't seem to be what you guys are doing with Wesnoth.

Actually we care a lot. We added -Werror to find errors earlier, older versions
of Wesnoth generated more warnings and those are now found and fixed faster.
I also run some stricter switches at times which also generate a lot of false positives
and need to be evaluated manually and thus aren't in the default errors.

But fixing all warnings for all compilers is hard, especially since a warning can be a
compiler bug [1] as well. Also some included library headers contain code that triggers
warnings. So we try to fix warnings if we run into them, but can't always fix all of them.

Regarding to the original warning, those seem to happen in the standard library which
makes fixing them hard for us, especially since I don't expect the gcc team to still
support 4.1.2.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40156

[ilor]

Exactly. Many of us compile with -Werror or equivalents, but some compilers are more pedantic than others. (especially MSVC is known to barf at random things)

Not really pedantic (as gcc can warn on stuff msvc accepts without comments, like "if (a && b || c) " in gcc 4.3), but just different. Which is good. While I was fixing msvc warnings I found a long forgotten mistake with some mutexes in sound handling noone would look at otherwise. If I had the time I'd have a go at wesnoth source with ICC just to see what new warnings there are