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

[Mathieu Malaterre]

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,
-- 
Mathieu
(*) run nm on the shared lib and you'll see " U " symbols.