[vtk-developers] VTK CVS broken: vtkInformationExecutivePortVectorKey and vtkExecutive link error in Debug only

[Amy Squillacote]

Mathieu Malaterre wrote:
> On 10/19/07, David C Thompson <dcthomp at sandia.gov> wrote:
>   
>>>>> Oddly, I do not see this problem on any dashboard.  But we have reproed
>>>>> this on two machine, with fresh checkouts and fresh builds.
>>>>>           
>>>> I certainly never saw it before I committed the move but perhaps I
>>>> didn't build static libraries? Could all of this be caused by
>>>> vtkSetObjectMacro() calling GetClassName() inside a vtkDebugMacro()?
>>>> With VTK_DEBUG_LEAKS turned on, does the vtkExecutive::Register() call
>>>> (also in vtkSetObjectMacro) also ask for the class name of the
>>>> vtkExecutive object? If so, it might be more difficult.
>>>>         
>>> Normally, I do build both as static libs and with VTK_DEBUG_LEAKS.  As a
>>> test, I tried also as shared libs, and without VTK_DEBUG_LEAKS, and
>>> without VTK_LEGACY_REMOVE, but I still get the same link error.
>>>       
>> Odd, it worked for me with shared libs + VTK_DEBUG_LEAKS -
>> VTK_LEGACY_REMOVE. If I don't hear back from Brad about how his
>> "radical" solution might work with wrappers, I'll get the
>> vtkInformationBase solution checked in over the weekend.
>>     
>
> You can build shared lib on linux without resolving all symbols(*)
> (they will be resolved at runtime). Try shared/static libs on Win32 or
> static lib on *NIX.
>
> 2 cents,
>   

I was seeing related errors on my Windows build yesterday with shared 
libs, but instead of getting undefined symbols, I was seeing errors 
about multiply defined symbols with the same classes listed in the 
original post.

- Amy

-- 
Amy Squillacote
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
Phone: (518) 371-3971 x106