[ITK-dev] Workaround for dynamic_cast on Mac OSX

Matt McCormick matt.mccormick at kitware.com
Mon Nov 14 18:36:00 EST 2016


On Mon, Nov 14, 2016 at 2:53 PM, Isaiah Norton <isaiah.norton at 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/


More information about the Insight-developers mailing list