[ITK-users] [ITK] Buffered Region out of Range error

[Michael Jackson]

That did not seem to help either. Any more ideas? Does ITK build some intermediate static libraries that have “managers” that load filters? I ran into an issue with our own code where we had static libraries with singleton “manager” design patterns that turned out not to work due to each library getting its own singleton instance.
--
Mike Jackson  [mike.jackson at bluequartz.net]


> On Oct 30, 2015, at 4:07 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
> 
> Thanks for the information.
> 
> It is hard to tell, but maybe it is related to factory registration.
> To test, try this:
> 
> In the plugin CMake code, add
> 
>  set(ITK_NO_IO_FACTORY_REGISTER_MANAGER 1)
> 
> before
> 
>  include(${ITK_USE_FILE})
> 
> Then see if neither plugins work, both plugins work, and one of the
> plugins works.
> 
> HTH,
> Matt
> 
> On Fri, Oct 30, 2015 at 1:36 PM, Michael Jackson
> <mike.jackson at bluequartz.net> wrote:
>> Some more data. If we create an intermediate library that links to ITK, called ITKSupport, and then have our plugins link against ITKSupport then the code executes correctly. Just another data point.
>> --
>> Michael A. Jackson
>> BlueQuartz Software, LLC
>> [e]: mike.jackson at bluequartz.net
>> 
>>> On Oct 30, 2015, at 12:57 PM, Michael Jackson <mike.jackson at bluequartz.net> wrote:
>>> 
>>> Yes. Verified. Both plugins are built as part of DREAM.3D and we don’t put any extra CXX_FLAGS in any of the CMake files. We also built with VERBOSE=1 and looked at the compile commands to ensure that what we wanted was actually being used. Then we looked at the libraries themselves with otool -L to ensure they all link against libC++. Which they do.
>>> 
>>> 
>>> --
>>> Michael A. Jackson
>>> BlueQuartz Software, LLC
>>> [e]: mike.jackson at bluequartz.net
>>> 
>>>> On Oct 30, 2015, at 12:05 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>>>> 
>>>> Hi Michael,
>>>> 
>>>> Sorry to be redundant, and just to be sure: are both A.plugin and
>>>> B.plugin built with the same C++ standard library, OSX deployment
>>>> target, and C++ standard?
>>>> 
>>>> Thanks,
>>>> Matt
>>>> 
>>>> On Fri, Oct 30, 2015 at 11:35 AM, Michael Jackson
>>>> <mike.jackson at bluequartz.net> wrote:
>>>>> 
>>>>> 
>>>>>> On Oct 29, 2015, at 11:40 AM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>>>>>> 
>>>>>> On Thu, Oct 29, 2015 at 10:00 AM, Michael Jackson
>>>>>> <mike.jackson at bluequartz.net> wrote:
>>>>>>> We also ran an experiment where we moved the ITK Dependency from just the
>>>>>>> plugin down into one of our lower level libraries. So now we have the plugin
>>>>>>> dependent on a lower level library which then is dependent on the ITK
>>>>>>> Libraries. Now the code seems to execute and produce results. This was on OS
>>>>>>> X 10.9 and 10.10. So it seems that there is some odd issue with loading the
>>>>>>> ITK libraries through a plugin mechanism? Does ITK need the “-fPIC” added to
>>>>>>> the list of compile commands?
>>>>>> 
>>>>>> If ITK is built in a plugin as shared libraries, then it will already
>>>>>> be built with -fPIC.
>>>>>> 
>>>>>> 
>>>>>>> Qt is actually built WITHOUT C++11 support but still links against libc++.
>>>>>>> They (the Qt Devs) set the OS X Min Deployment Version to 10.7. I have no
>>>>>>> idea what that triggers or not.
>>>>>> 
>>>>>> All code should be built with the same C++ standard and OSX deployment
>>>>>> target. When building ITK and related code, set
>>>>>> CMAKE_OSX_DEPLOYMENT_TARGET [1] to 10.7 to ensure all binaries are
>>>>>> using consistent libraries.
>>>>>> 
>>>>>> HTH,
>>>>>> Matt
>>>>>> 
>>>>>> [1] https://cmake.org/cmake/help/v3.3/variable/CMAKE_OSX_DEPLOYMENT_TARGET.html
>>>>> 
>>>>> Matt,
>>>>> We have verified that ALL dependent libraries are built with libC++, 10.7 as the min deployment, C++11 enabled. This goes for Boost, HDF5, Eigen, ITK, and Qt 5.5.1. We still have the issue. We can also reproduce that if we move the dependency to a lower level then the issue goes away. So it would seem that there is a problem with multiple plugins being dependent on the same External library. in this case it is ITK. I’ll try to diagram below.
>>>>> ## Failure Mode ##
>>>>> A.plugin depends on ITK
>>>>> A.plugin depends on SIMPlib.
>>>>> 
>>>>> B.plugin depends on ITK
>>>>> B.plugin depends on SIMPlib.
>>>>> 
>>>>> B.plugin will fail to execute properly.
>>>>> 
>>>>> ## Success Mode ##
>>>>> A.plugin depends on SIMPlib.
>>>>> SIMPlib depends on ITK
>>>>> 
>>>>> B.plugin depends on SIMPlib.
>>>>> SIMPlib depends on ITK
>>>>> 
>>>>> The DREAM.3D filters both execute properly and give the proper output.
>>>>> 
>>>>> --
>>>>> Michael A. Jackson
>>>>> BlueQuartz Software, LLC
>>>>> [e]: mike.jackson at bluequartz.net
>>>>> _____________________________________
>>>>> 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://www.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-users
>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20151102/4a4b9710/attachment.html>