glmark2 ftbfs

[Fathi Boudra]

https://launchpadlibrarian.net/124086273/buildlog_ubuntu-precise-armhf.glmark2_2012.08%2Bbzr252%2B24%2B201211262012~precise1_FAILEDTOBUILD.txt.gz

packaging branch hasn't been updated.

[Jesse Barker (jesse-barker)]

It turns out this is something that gcc 4.6 complains about, but gcc 4.7 doesn't (might be good to get someone from toolchain to comment on whether this is a change in the c++ standard, or just a change in gcc behavior).

Here's something I'm a bit confused about: The build log in the bug report, by name at least, indicates that the build is of glmark2 2012.08 and targeted at precise. 2012.08 doesn't have code that would trip this error (certainly not at that location), and the 2012.11 release (and trunk beyond) isn't supposed to build for precise. It's possible I've messed up the changes to the packaging branch (lp:~glmark2-dev/glmark2/glmark2-package) for the 2012.11 release, but my intent was to only target quantal (though, not because I was aware of the toolchain thing).

[Jesse Barker (jesse-barker)]

OK, to follow up on my last comment, there is a two-fold answer here:

1) This was due to a clarification in the C++ standard (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#799) that was implemented for gcc 4.7 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51379). So, gcc 4.6 won't give you the "right" result for this code path. (Thanks to Michael Hope for finding the right referenes on this as my own searches didn't turn up satisfying answers).

2) Peeking under the covers, even though the variable being cast and the function argument have different explicit types, their underlying type is the same (EGLNativeWindowType is always Window for X11, and so they'll always be the same type), and the cast can actually go away. This is now committed to lp:glmark2.

[Fathi Boudra (fboudra)]

Thanks Jesse. glmark2 2012.11 release now builds fine and is available in Linaro Overlay PPA.