On Sun, Feb 24, 2013 at 10:35:19AM +0100, Guus Sliepen wrote: > On Sun, Feb 24, 2013 at 04:48:06AM +0100, Adam Borowski wrote: > > > > This bug is already fixed in the version in experimental. > > > > I'm afraid this is not true. Your changes fix unrelated problems (-flto > > breakage on some architectures) but not the COMPILE_CHECK issue. > > Oh, but upstream already changed the COMPILE_CHECK macros in 0.11.
If you mean commit d2628144 from Jun 3 2012, it's not enough. It was enough at that point, but gcc-4.8 was far from being released (Feb 9 2013). I made a further fix on Aug 27, which narrowly missed the branching of 0.11. I cherry-picked that commit into 0.11 only today at 5am (and it's in no point release yet). > I tried them out and they seemed to work without problems, but maybe I did > something wrong? It worked for me in pbuilder (gcc-4.7) but not on my live system (gcc-4.8), where it fails on this COMPILE_CHECK, same as in Matthias' rebuild. > Ok then I did not correctly check whether this really fixed the issue. I guess > I didn't use gcc 4.8 after all. Seems so -- it's in gcc-defaults only in experimental. > > Since unstable still defaults to gcc-4.7, I don't think there's a reason > > to hurry, though. 0.12 will come in 1-2 months, and if per some chance > > wheezy gets released sooner, I can cut a 0.11.3. > > > > If you want to fix this now, please either take that commit, or enclose > > COMPILE_CHECK macros in tilepick.cc in a dummy function. Building with > > -std=c++11 would be another option (static_assert() goodness), but 0.11 > > produces so many warnings about auto_ptr and %"PRId64 that let's not > > even bother. > > Or just define _lint, so these COMPILE_CHECKS just go away? Technically, yes. It'd just be in bad style :) -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
