I have been trying to build ITK 5.0 (rc1 or master) in Windows with BUILD_SHARED_LIBS selected (to generate ITK dlls, as I’ve done for previous releases - e.g., 4.12.0), but without success.
My setup is: Windows 8.1 Pro, Visual Studio 2015 and CMake 3.13.1.
The steps I followed can be reproduced by:
(1) Downloading the sources from the ITK5.0rc1 release (https://github.com/InsightSoftwareConsortium/ITK/releases/tag/v5.0rc01) or the master branch;
(2) Configuring CMake with default parameters, select “BUILD_SHARED_LIBS” and deselect “BUILD_TESTING”, and then generate project;
(3) Build using VS 2015 in release mode.
While building the solution, within the ITKCommon project, the following error trace appears:
126>------ Build started: Project: ITKCommon, Configuration: Release x64 ------
126> Building Custom Rule D:/Code/ITK5.0rc01/src/Modules/Core/Common/src/CMakeLists.txt
126> CMake does not need to re-run because D:/Code/ITK5.0rc01/binVC14/Modules/Core/Common/src/CMakeFiles/generate.stamp is up-to-date.
126> itkBuildInformation.cxx
126>d:\code\itk5.0rc01\src\modules\core\common\include\itkEventObject.h(96): error C2071: ‘itk::EventObject::EventFactoryFunction’: illegal storage class
This error (linked to the EventObject class) is then thrown multiple times, when generating code for other itk cxx files, resulting in dozens of projects failed to build.
Thank you in advance.
Best regards,
Sandro.
Side note:
If i deselect BUILD_SHARED_LIBS, the build is still unsuccessful, throwing the following error:
D:\Code\ITK5.0rc01\src\Modules\Core\Common\src\itkProcessObject.cxx(54): error C2440: ‘initializing’: cannot convert from ‘const char [3]’ to ‘const char’.
This error seems to be associated with the C++11 standard and compiler conformance options, and may be solved by changing the associated char[][] to a std::string[]. If modified, the build is finished successfully.
Does your Visual Studio 2015 has Update 3 (the latest one available for it)? A relatively recent git-master (826ac2b) builds on my computer using VS2015U3.
@dzenanz Do you know if this private type, EventFactoryFunction, is actually being used somewhere? I would expect it to be used in itkEventObject.cxx, but I can’t find it!
I indeed din’t had Update 3. After updating, ITK built successfully without further changes. Thank you!
I will now check if it’s fully working, otherwise I will let you know.
Btw, is there any (hidden) flag I should set during CMake to improve performance in the new ITK5.0 (like ITK_LEGACY_REMOVE) or so? I have seen some comments about it in the latest release infos, but didn’t knew exactly whether they are active per default (or not since much is still under experimentation).
In my projects, I am mostly using NeighborhoodOperatorImageFilters (with Gaussian and GaussianDerivative operators), both in CPU and GPU.
On a different note, and going back to my own project, was there any major change to the GPUNeighborhoodOperatorImageFilter class in ITK 5.0? I sucessfully executed my application using the CPU version of this class without any change to my code. But I was then trying to run the GPU version and the following error now appears which does not seem to be related to my code:
Error C2664 ‘bool itk::GPUKernelManager::SetKernelArgWithImageAndBufferedRegion(int,cl_uint &,TGPUImageDataManager *)’: cannot convert argument 3 from ‘const itk::GPUImageDataManager<itk::GPUImage<double,2>> *’ to ‘GPUInputManagerType *’ d:\code\itk5.0rc01\src\modules\filtering\gpuimagefilterbase\include\itkGPUNeighborhoodOperatorImageFilter.hxx 205
Turning ITK_LEGACY_REMOVE ON should help things a little.
We didn’t make significant changes to GPU infrastructure, but some bug fixes do occur over time. In order to narrow it down, can you also try recently released 4.13.2?
If that does not help you fix the error, please make a MWE which demonstrates the problem?
I had already turned ITK_LEGACY_REMOVE and ITK_FUTURE_LEGACY_REMOVE ON when running cmake, and after all that was the problem with the GPU class.
I tried to compile the 4.13.2 version and got the same error when building, but with my previous version (4.12.0) was working fine. I went back and tried to identify the difference in configuration between versions, and the difference was the ITK_FUTURE_LEGACY_REMOVE option. If I deselect that one, the GPUNeighborhoodOperatorImageFilter works fine for all versions (4.12, 4.13.2 and 5.0rc01). I don’t know what this specific DEFINE does, but it seems to be the cause for the building error.
No issue with ITK_LEGACY_REMOVE.
By the way, just for reference and with respect to performance, for my application I haven’t noticed any difference between versions (4.12, 4.13.2 and 5.0) when using the GPUNeighborhoodOperatorFilter. However, there is a slight improvement (5 to 10%) for the CPU version of this class (NeighborhoodOperatorFilter) between version 4.12 and the newer ones (4.13.2 and 5.0).
That sounds about right. GPU filters were not a focus of improvement efforts, so it is no surprise their performance is the same.
Search “ITK_FUTURE_LEGACY_REMOVE” (22 hits in 11 files):
C:\Dev\ITK-git\cmake\ITKConfig.cmake.in (2 hits)
Line 39: set(ITK_FUTURE_LEGACY_REMOVE "@ITK_FUTURE_LEGACY_REMOVE@")
Line 39: set(ITK_FUTURE_LEGACY_REMOVE "@ITK_FUTURE_LEGACY_REMOVE@")
C:\Dev\ITK-git\CMakeLists.txt (3 hits)
Line 264: # These ITK_FUTURE_LEGACY_REMOVE are another level of granularity for
Line 266: option(ITK_FUTURE_LEGACY_REMOVE "Completely remove compilation of code which will become deprecated by default in ITKv5." OFF)
Line 272: mark_as_advanced(ITK_LEGACY_SILENT ITK_LEGACY_REMOVE ITK_FUTURE_LEGACY_REMOVE ITKV4_COMPATIBILITY)
C:\Dev\ITK-git\Documentation\ITK5MigrationGuide.md (1 hit)
Line 19: Code which was marked as `ITK_FUTURE_LEGACY_REMOVE` has been now
C:\Dev\ITK-git\Documentation\ReleaseNotes\4.13.md (2 hits)
Line 384: BUG: itkSpatialObject.cxx was not respecting ITK_FUTURE_LEGACY_REMOVE
Line 407: BUG: Respect ITK_FUTURE_LEGACY_REMOVE
C:\Dev\ITK-git\Documentation\ReleaseNotes\4.4.md (2 hits)
Line 288: ` COMP: Missing patch for ITK_FUTURE_LEGACY_REMOVE`\
Line 295: ` BUG: ITK_FUTURE_LEGACY_REMOVE must cmake configured`\
C:\Dev\ITK-git\Modules\Core\Common\include\itkMacro.h (7 hits)
Line 246: #if defined ( ITK_FUTURE_LEGACY_REMOVE )
Line 650: #if defined ( ITK_FUTURE_LEGACY_REMOVE )
Line 1102: #if defined ( ITK_FUTURE_LEGACY_REMOVE )
Line 1105: // through manual setting of a compiler define -DITK_FUTURE_LEGACY_REMOVE
Line 1106: // ("/DITK_FUTURE_LEGACY_REMOVE /EHsc" with Visual Studio)
Line 1121: #else // defined ( ITK_FUTURE_LEGACY_REMOVE )
Line 1136: #endif // defined ( ITK_FUTURE_LEGACY_REMOVE )
C:\Dev\ITK-git\Modules\Core\Common\include\itkThreadSupport.h (1 hit)
Line 125: #if ! defined ( ITK_FUTURE_LEGACY_REMOVE )
C:\Dev\ITK-git\Modules\Core\Common\src\itkConfigure.h.in (1 hit)
Line 84: #cmakedefine ITK_FUTURE_LEGACY_REMOVE
C:\Dev\ITK-git\Modules\Filtering\ImageIntensity\include\itkArithmeticOpsFunctors.h (1 hit)
Line 248: #if ! defined ( ITK_FUTURE_LEGACY_REMOVE )
C:\Dev\ITK-git\Modules\Filtering\ImageStatistics\include\itkAdaptiveHistogramEqualizationImageFilter.h (1 hit)
Line 120: #if ! defined ( ITK_FUTURE_LEGACY_REMOVE )
C:\Dev\ITK-git\Utilities\ITKv5Preparation\UseNativeC++Syntax.sh (1 hit)
Line 8: # Step 1 for migration to ITKv5: Continue building your toolkit with ITKv4, but use -DITK_FUTURE_LEGACY_REMOVE:BOOL=ON
This option does not affect many things. It is not quite clear to me how the above files influence GPUNeighborhoodOperatorFilter. You might have more insight into causation.
Not many ideas…based on the includes of my own project and the classes I know that I am using through the use of GPUNeighborhoodFilter, I guess it should be something related with the “Core\Common” part of ITK. Among those files with this option somehow used, the one that I think has more potential for generating the build issue is the itkMacro.h. Several defines and macros are changed based on that flag, and they seem to be common things used among other classes (like whether to use “constexpr” or replace it, or the macro to create templated function).
