Comment 1 Mike Massonnet 2009-01-18 20:47:55 CET

Created attachment 2092 
fix exo configure script

Comment 2 Mike Massonnet 2009-01-18 20:48:13 CET

Created attachment 2093 
fix thunar configure script

Comment 3 Benedikt Meurer 2009-01-18 21:07:02 CET

I'd suggest to file a bug report to Glib and in the mean time disable this specific warning instead of removing -Werror.

There is already a bug report filed at glib.
http://bugzilla.gnome.org/show_bug.cgi?id=316221

Oh, sorry missed that Mike already attached a link.

Comment 6 Mike Massonnet 2009-01-18 21:41:00 CET

(In reply to comment #3)
> I'd suggest to file a bug report to Glib and in the mean time disable this
> specific warning instead of removing -Werror.

But what do you think about moving it from --enable-debug=yes to =full?  That's what is done by applying the patches.

Comment 7 Benedikt Meurer 2009-01-18 21:47:59 CET

Nope, it should stay as-is. Non-trivial problems aren't always reported as error by gcc, which might easily lead to broken builds (gcc still generates invalid code, though most of the time it's C++ then). Better catch these warnings during compilation stage than having to track down crashes later. And of course, this way developers will have a hard time committing obviously b0rked code.

(In reply to comment #7)
> Nope, it should stay as-is. Non-trivial problems aren't always reported as
> error by gcc, which might easily lead to broken builds (gcc still generates
> invalid code, though most of the time it's C++ then). Better catch these
> warnings during compilation stage than having to track down crashes later. And
> of course, this way developers will have a hard time committing obviously
> b0rked code.

What about using -Wno-error=strict-aliasing as described in comment #30 in the bug filed to glib?

Comment 9 Benedikt Meurer 2009-01-18 22:15:26 CET

As said, that should be used as temporary work-around.

Comment 10 Mike Massonnet 2009-01-18 22:19:35 CET

Ok, thanks for your opinion ;-)

Comment 11 Mike Massonnet 2009-01-18 22:28:11 CET

Created attachment 2094 
ignore strict aliasing

There is a check to see whether the compiler supports it (just like -Wall -Werror) cause this is one of the features introduces in gcc 3.4.

Comment 12 Mike Massonnet 2009-01-18 22:28:46 CET

Created attachment 2095 
ignore strict aliasing (thunar)

same comment as for exo

-Werror is breaking Terminal with vte 0.17.4-2 here because of deprecated functions. And turning off all debugging to fix that isn't really attractive imho.

Comment 14 Nick Schermer 2009-08-21 07:27:00 CEST

Looks like the glib bug is fixed, compiles fine here with strict aliasing.

Terminal error is fixed btw (only anti aliasing when debugging is disabled).

Comment 15 Nick Schermer 2009-08-27 07:10:00 CEST

Fixed in Glib 2.19.8.

http://git.gnome.org/cgit/glib/commit/?id=c8e37b63e74fafdc1f299ec139677ad0e37676c3