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

Brad King brad.king at kitware.com
Thu Oct 18 16:05:31 EDT 2007


Berk Geveci wrote:
> I don't have much time to think about this but maybe you could break
> vtkInformation into two? A superclass such as vtkInformationBase that
> does not have anything Executive specific (in Common) and a
> vtkInformation subclass in Filtering? vtkDataArray could have a
> vtkInformationBase and everything else could keep using
> vtkInformation... Just an idea.

The only reason vtkInformation depends on vtkExecutive is because it
provides convenience methods to get at pipeline information without
including all the information key headers.

The correct split would be to leave "vtkInformation" in Common, and then
create a "vtkPipelineInformation" in Filtering that derives from
vtkInformation and just adds the extra convenience methods.  However,
this will break way too much code.  I think renaming the class in Common
to vtkInformationBase and then leaving vtkInformation in Filtering will
work.  Only code in Common should use vtkInformationBase and everything
else should use vtkInformation.  This split is similar to how
vtkObjectBase provides just the basic functionality (reference counting
and VTK-RTTI) and vtkObject adds all the observer and debug stuff.  Now
vtkInformationBase will provide the basic information storage/retrieval
interface, and vtkInformation will add all the stuff useful for pipelines.

On the other hand I originally intended vtkInformation to never be a
class hierarchy so that information objects could be passed around
freely.  With the split it will not be safe to pass array information
objects to things looking for pipeline information because the
vtkInformationBase object cannot be downcast to vtkInformation even
though the only difference is the availablility of a few non-virtual
methods.

I propose the following (radical) solution.  Instead of splitting the
*interface* we should split the *implementation*.  All of the offending
methods are non-virtual, so they will only be needed by the linker if
someone calls them.  Code that links to vtkCommon only cannot possibly
need information about vtkExecutive and therefore will not be calling
the methods.  So what we need to do is take the implementation of
executive-related vtkInformation methods and move it out of
Common/vtkInformation.cxx and put it in a new
Filtering/vtkInformation.cxx file.  The filtering version of the file
would contain something like

------------------------------------------------------------------------
#include "vtkInformation.h"
#include "vtkInformationExecutivePortKey.h"

void vtkInformation::CopyEntry(vtkInformation* from,
                               vtkInformationExecutivePortKey* key, int)
{
  key->ShallowCopy(from, this);
}

void vtkInformation::Append(vtkInformationKeyVectorKey* key,
                            vtkInformationExecutivePortKey* value)
{
  key->Append(this, value);
}
...
------------------------------------------------------------------------

There is nothing wrong with having the forward declarations of the
classes and methods in vtkInformation.h even though vtkCommon does not
provide the methods.  By keeping the implementation in a separate object
file from the rest of vtkInformation the linker will not require
vtkExecutive code to be present unless one of the methods is actually
called.

-Brad

> On 10/18/07, *David C Thompson* <dcthomp at sandia.gov
> <mailto:dcthomp at sandia.gov>> wrote:
> 
>     > We are unable to build VTK from CVS.  It Release it links, in Debug it
>     > does not.  The error is:
>     >
>     > Linking CXX executable ../../../bin/CommonCxxTests
>     > Undefined symbols:
>     >   "typeinfo for vtkExecutive", referenced from:
>     >       typeinfo for vtkExecutive*in
>     libvtkCommon.a(vtkInformationExecutivePortVectorKey.o)
>     > ld: symbol(s) not found
>     >
>     > We see that vtkInformationExecutivePortVectorKey was recently
>     moved from
>     > Filtering to Common, but vtkExecutive is still in
>     Filtering.  Should it
>     > move too?
>     I will be happy to move vtkExecutive to Common if Kitware approves, but
>     I doubt they will because it would involve moving the following classes
>     as well (since vtkExecutive.cxx includes them):
>        vtkAlgorithm
>        vtkAlgorithmOutput
>        vtkDataObject
>     And then all of *their* dependencies would have to be moved. I think an
>     aesthetically more pleasing solution would be to eliminate
>     vtkInformation's dependency on vtkExecutive but I don't see a simple way
>     to do this. Do any of you?
> 
>     > 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.
> 
>             David
> 
>     _______________________________________________
>     vtk-developers mailing list
>     vtk-developers at vtk.org <mailto:vtk-developers at vtk.org>
>     http://www.vtk.org/mailman/listinfo/vtk-developers
> 
> 




More information about the vtk-developers mailing list