1. Jason McKesson
  2. gltut

Issues

Issue #75 invalid

Tutorials 12 and 16 do not build with GCC 4.7

Nikos Platis
created an issue

The error messages for tutorial 12 are

{{{ In file included from Lights.h:12:0, from Lights.cpp:13: ../framework/Interpolators.h: In instantiation of ‘void Framework::ConstVelLinearInterpolator<ValueType>::SetValues(const BidirectionalRange&, bool) [with BidirectionalRange = std::vector<glm::detail::tvec3<float> >; ValueType = glm::detail::tvec3<float>]’: Lights.cpp:66:35: required from here

../framework/Interpolators.h:183:5: error: ‘distance’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]

Lights.cpp:38:7: note: ‘float distance(const vec3&, const vec3&)’ declared here, later in the translation unit }}}

and similarly for {{{ Lights.cpp:133:7: note: ‘float GetValue(const MaxIntensityData&)’ declared here, later in the translation unit }}} and {{{ Lights.cpp:134:7: note: ‘float GetTime(const MaxIntensityData&)’ declared here, later in the translation unit }}}

This is due to a change in (incorrect) behavior of gcc, as documented in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29131 and the solution is to (at least) declare these functions before including "Lights.h" (or actually before including "../framework/Interpolators.h").

In tutorial 16 (LightEnv.cpp) this is accomplished by simply moving the #include "LightEnv.h" after the definition of distance().

In tutorial 12 (Lights.cpp) you could move all declarations of these functions at the top (just like in tutorial 16/LightEnv.cpp) and also move the #include "Lights.h" below them.

Comments (3)

  1. Jason McKesson repo owner

    Those free functions should be found. The specification states that dependent names where the types are not fundamental types should be handled by argument-dependent lookup. So they shouldn't require being defined outside of them.

    According to comment 5 of the bug you linked to, what I did ought to work. None of those are fundamental types.

    It looks like in fixing the problem for fundamental types, they broke it for others.

  2. Nikos Platis reporter

    It's quite interesting: the simple code you posted in the comp.std.c++ group actually compiles with GCC 4.7 as well, whereas (a) the example in the initial bug using fundamental types does not compile (correctly) and (b) the code of Tutorials 12 and 16 does not (probably incorrectly).

    It may well be a bug in GCC 4.7.

  3. Log in to comment