Hi Isaiah, Here is some more information and background.
> What is the rationale behind creating so many separate, statically-linked > Python modules? (78 `_ITK*Python.so` files on my machine). Creating a single > bundle instead should resolve the original issue, and might also reduce the > size of the final library [3]. For background, the GlobalTimeStamp, is a very important variable in ITK (and VTK). This is an atomic integer that gets incremented when any itk::Object (most classes in ITK) is "Modified", i.e. changed to note that it should be updated in a processing pipeline. So, almost all ITK-based code needs it, and it needs to be global across the entire program. The GlobalTimeStamp lives in and is used my itk::TimeStamp.cxx, and it is incremented on every call to ::Modified(). The itk::TimeStamp class is linked into libITKCommon. When ITK is built with shared libraries, libITKCommon is shared, and everything shares the GlobalTimeStamp. When ITK is built with static libraries, every binary that links in libITKCommon will get its own GlobalTimeStamp. Unfortunately, a shared libITKCommon is not always possible. For the official Python packaging format, wheels, native libraries are not yet officially supported [1]. The advantages of not linking everything into one, giant, monolithic `_ITK*Python.so` are that 1) we can lazily load only the parts of the library that we need, and 2) the brilliant ITK community members can extend ITK to create their own ITK Python module. For example, see the awesome ITKMinimalPathExtraction [2] or ITKIsotropicWavelets [3] modules. While I also investigated, for example, using CMake object libraries to make itk::TimeStamp an exported symbol in _ITKCommonPython.so and only linked there [4], this is a more complex build configuration. Additionally, according to the Python documentation, exporting extra symbols in a CPython extension module is officially not supported [5]. In practice, I have found that extra symbols can segfault the process on module import with Python 3.5 on Windows. So, the sharing is done the officially supported way, via PyCapsule. > Additionally, I am wondering if cross-module `dynamic_cast` works correctly > in the current situation -- because the typeinfos in each static module .so > have different addresses [4]. (I'm not sure how to create a situation to > test this from Python) Yes, since the Python wrapping covers the entire toolkit, it is an excellent stress test for the dynamic_cast issue. When we developed the dynamic_cast patch, we used Python wrapping with static libraries and experimentally enabled hidden symbols by default [6]. Without the dynamic_cast fix, the Python tests failed, and with the fix, they pass. It turns out that we missed some mark-up on a few classes as indicated by warnings in the Python wrapping and non-wrapping test failures, but we are working on resolving those now. Thanks, Matt [1] https://mail.python.org/pipermail/wheel-builders/2016-April/000090.html [2] https://github.com/InsightSoftwareConsortium/ITKMinimalPathExtraction [3] https://github.com/phcerdan/ITKIsotropicWavelets [4] https://github.com/thewtex/ITK/commits/thewtex-PythonModifiedTime55 [5] https://docs.python.org/3.5/extending/extending.html#providing-a-c-api-for-an-extension-module [6] http://review.source.kitware.com/#/c/21766/ _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/insight-developers
