[ITK-users] [ITK] Buffered Region out of Range error
Michael Jackson
mike.jackson at bluequartz.net
Fri Oct 30 12:57:15 EDT 2015
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
More information about the Insight-users
mailing list