On Mon, Nov 14, 2016 at 2:53 PM, Isaiah Norton <isaiah.nor...@gmail.com> wrote: > Hi Matt, > >> >> Here are the tests: >> http://review.source.kitware.com/#/c/21755/ >> >> where reasonable export specification is added in both ITK and the >> client libraries. But, dynamic_cast fails on OSX: > > > The export changes in this merge request don't seem to be related to the > casts that are failing.
Correct. This patch is intended to just be a self-contained test that demonstrates the issue. > A small change [1] allows all of the tests to pass. > Of course, many more export annotations would be required for general > applicability. Thanks for implementing and testing a possible solution. ITK_API_EXPORT does not work with Windows static builds, but we could try ITKCommon_TEMPLATE_EXPORT, which we developed for explicit template instantiation markup [1]. However, more testing is required to determine if this works for implicit template instantiation on all platforms and does not have other side effects. A statement in one of the links you referenced [2], "there is unfortunately no way to mark only the (implicitly generated) RTTI symbols for default visibility" implies caution. > There is a compiler option that could potentially address the issue > "-fvisibility-ms-compat" -- see [2]. As mentioned on that page, these RTTI > type_info issues *also break exception handling*, so simply changing all of > the ITK `dynamic_cast` uses to a custom implementation will not fully > address the issue (I have encountered this a number of times in Slicer: ITK > exceptions thrown by dynamic libraries are incorrectly identified). > > Alternatively, if there is concern about symbol bloat (I've seen some > threads to that effect related to SimpleITK) then a linker script could be > used to export all `_ZTN*` symbols. Thanks for the pointer. Symbol bloat is a concern. Also, there are potential issues with how symbols are handled with dlopen and RTLD_GLOBAL, along with keeping a GlobalModifiedTime across the process, especially with respect to Python wrapping. This patch remarks on some of the issues we are currently trying to address [3]. We will test further with Python wrapping for OSX with the ITKCommon_TEMPLATE_EXPORT approach, then investigate -fvisibility-ms-compat if that does not prove viable. Thanks, Matt [1] https://github.com/InsightSoftwareConsortium/ITK/commit/d9633b7562c8223bf5ea8e1ee08eaa2e91506e58 [2] https://lists.freedesktop.org/archives/libreoffice-commits/2015-January/091572.html [3] http://review.source.kitware.com/#/c/21361/ _______________________________________________ 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
