Page MenuHomePhabricator

Check that ITK and VTK are built as shared libs to prevent strange pipeline errors in MITK
Closed, WontfixPublic

Description

When using static (non-shared) VTK libs with shared (dynamically-linked) MITK libs, the 5.x VTK pipeline mechanism does not work correctly, at least in some cases.

System: Windows Vista, VC 2008, VTK 5.4.2.

Examples:

  • vtkMitkThickSlicesFilterTest fails (SetInput does not really sets something, a GetInput immediately afterwards returns NULL).
  • The ImageCropper module does not show the bounding-object.

Maybe the build system can prevent building MTIK shared with VTK static?

At least there should be a warning in the documentation.

Event Timeline

We saw this already with ITK. It does not work since the modified time is counted up in a global variable, which exists multiple times if VTK or ITK libs are linked as static versions. If I remember correctly ITK did not "export" correctly whether it was built shared or static.

Next steps:

    • re-check if ITKConfig.cmake and VTKConfig.cmake contain correct information about the shared lib status, otherwise find some workaround to determine the library type
  • add checks to MITK to prevent these strange errors.

[SVN revision 24820]
FIX (#4745): check that ITK and VTK are built as shared libraries

ITK on windows does not set the ITK_BUILD_SHARED variable correctly ...

[SVN revision 24824]
COMP (#4745): deactivate the buggy ITK check for shared libraries

This issue should not appear so often now, because the superbuild mechanism propagates the chosen value (BUILD_SHARED_LIBS:BOOS = [ON | OFF] ) to all sub-projects.

But it remains a 'nice to have' feature, since one can still use externally compiled VTK/ITK (or other toolkits).

nolden claimed this task.

Most people do use superbuild, no additional checks necessary

kislinsk removed nolden as the assignee of this task.
kislinsk added a project: Bulk Edit.
kislinsk removed a project: Bulk Edit.