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

[Hans de Goede]

Michael Schwendt wrote:
> 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.
> 

Quoting myself: "move the template entirely to Collision.cpp", which would 
effectively make it a private template only meant for use inside Collision.cpp, 
so it will not be possible for other .cpp files to use it and therefore it 
cannot be "instantiated with a different type parameter that is not covered 
inside Collision.cpp", since all use will be in Collision.cpp and only in 
Collision.cpp .

Regards,

Hans