Massrebuilds for GCC 4.3 coming soon to a buildsystem near you!

Michael Schwendt mschwendt at gmail.com
Wed Feb 13 16:53:04 UTC 2008


On Wed, 13 Feb 2008 16:45:17 +0100, Hans de Goede wrote:

> Jon Ciesla wrote:
> >> On Wed, 13 Feb 2008 07:25:56 -0600 (CST), Jon Ciesla wrote:
> >>
> >>>>> I've got all mine patched and done for 4.3 but xmoto, which I've got
> >>>>> partway fixed but am stuck.  Anyone understand this?
> >>>>>
> >>>>> http://koji.fedoraproject.org/koji/getfile?taskID=406771&name=build.log
> >>>> Scene.o: In function `CollisionSystem::CollisionSystem()':
> >>>> Scene.cpp:(.text._ZN15CollisionSystemC1Ev[CollisionSystem::CollisionSystem()]+0xd1):
> >>>> undefined reference to `ElementHandler<Entity>::reset()'
> >>>>
> >>>> This usually means that the definition of
> >>>> class template ElementHandler's member function reset is not included
> >>>> in the translation unit, only the declaration.
> >>>>
> >>>> Find out where it's defined, and make sure that scene.cpp includes
> >>> that
> >>>> file.
> >>> It's defined in Collision.h in the parent directory, and it is included
> >>> in
> >>> Scene.cpp, but I noticed in Scene.h it uses:
> >>>
> >>> #include "Collision.h"
> >>>
> >>> rather than:
> >>>
> >>> #include "../Collision.h"
> >>>
> >>> So I patched that, but it doesn't help.
> >> It's declared in Collision.h but defined only in Collision.cpp, which
> >> doesn't work as it is a template. The author had tried to also move the
> >> ctor into the .cpp file and mentions in a comment that it didn't compile.
> >> Moving the definition of ElementHandler<T>::reset() method into the
> >> Collision.h file would fix this (but it's likely not the only definition
> >> that needs to be moved).
> > 
> > That makes sense.  As my c++ are not quite up to this, I've sent this
> > upstream.  Thanks all!
> > 
> 
> 
> Attached is a patch which fixes this by un-inlining the Collision constructor. 
> Actually it seems that the best way to fix this is to un-inline all Collision 
> members which use the template and move the template entirely to Collision.cpp

Note, however, that it only fixes the current implementation, not the bad
design (the splitting of the template declaration/definition). It would
break again as soon as the class template were instantiated with a
different type parameter that is not covered inside Collision.cpp.




More information about the fedora-devel-list mailing list