Hello, I had one more thought on this issue as I was reading on other topics.
There appears to be ways to pass the linker list of symbols or REGEX of symbols to export (-export-symbols and -export-symbols-regex). Perhaps instead of monkeying too much with the ITK casting and class export specification, maybe a regex for the RTTI or a generated list of symbols could be generated to export for the problematic configuration for WrapITK? Just another thought. Brad > On Nov 15, 2016, at 10:17 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] > <blowek...@mail.nih.gov> wrote: > > >> On Nov 14, 2016, at 6:18 PM, Matt McCormick <matt.mccorm...@kitware.com> >> wrote: >> >> On Mon, Nov 14, 2016 at 2:18 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] >> <blowek...@mail.nih.gov> wrote: >>> Matt, >>> >>> I believe that GCC 4.1 also had a very similar problem to what is occurring >>> in with Apple Clang now. >> >> Thanks to the GCC version dashboard builds that you maintain, we >> should be able to see if other GCC's have that issue, too :-). >> > > Based on the good information Isaiah has referenced: It may be that the prior > gcc 4.1 behavior was due to the version of libstdc++ that was distributed > with gcc 4.1, so with the dashboard system using gcc4.1 with > libstdc++.so.6.0.19 at runtime may have different behavior. > >> >>> It’s interesting to note that Slicer CLI interface does not contain ITK >>> templated objects. Does Slicer use ITK objects any where in it’s public >>> API’s? >> >> Note that this issue becomes predominantly problematic when ITK >> templated objects are not in the ABI but used internally (as in the >> test case). >> >> >> Thanks, >> Matt > > I’m not sure what the right term is. Yes, in the test case the templated > object is not explicitly in the ABI/API of the library, but the method > exposes private templated objects by producing objects which are intended to > be “cast" to the templated object. So by documentation and behavior instances > of private templated object are exposed in the API of the test case? > > So my point? I think that developing a clean interface without excessive > multiple instances as well as not exposing private instance is important and > should be the first approach. If there are places remaining in Slicer or ITK > which “expose” private symbols I would like to help to directly address them. > > I also acknowledge that some interfaces were not designed with this in mind > and are limited in their ability to meet these best practices and therefor > need the “SafeDownCast” work around. > > I think I have gone past my 2 cents on this issue. > > HTH, > Brad > _______________________________________________ > slicer-devel mailing list > slicer-de...@bwh.harvard.edu > http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel > To unsubscribe: send email to slicer-devel-requ...@bwh.harvard.edu with > unsubscribe as the subject > http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Developers/FAQ _______________________________________________ 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
