Hello everyone,
I saw that Visual Studio 2019 had been released as a preview (actually back in December). Out of curiosity, has anyone tried to build ITK with it and has anyone encountered any problem?
We have see reports in the GitHub issue tracker from a Visual Studio developer (they are using ITK in their regression test suite). The reported issues have been resolved.
1 Like
Even Visual Studio 2017 is not quite stable yet, so I did not dare try 2019 yet. I had a feeling they will simply declare VS2017 āfinishedā, publish VS2019, and keep updating it as they had VS2017 so far. This is just my impression, though.
I tried to compile ITK with it and it was failing on some vnl targets. Iāll test it again after the next preview is released 
Hello folks,
Iām digging up the topic to know if any of you has tried VS2019 with ITK5.0 recently?
Iām wondering if I should update !
Tim
Yes, I tried it. With default setting, it fails compiling due to buggy asynchronous writing to debug symbol database. Workaround is to add /FS to CMAKE_CXX_FLAGS so it reads /DWIN32 /D_WINDOWS /W3 /GR /EHsc /FS.
3 Likes
Thanks for the follow-up and reporting to VS team Dženan !
I will give a shot to VS2019, but as always it seems that we have to wait a bit to have a stable VS solutionā¦
1 Like
I am building SimpleITK against ITK 4.13.2 on
Azure DevOps with success.
1 Like
Are you just building SimpleITK against pre-built ITK, or do you build both?
MSVC 16.1.1 (a very recent stable version) was choking on itkv3p_netlib.pdb and one other library (if I remember correctly). For some reason, not everyone encounters this. Also, version 16.0.0 was failing on some 200-300 libraries out of default about 600 in ITK. Which means they are making progress, and thus probably aware of the problem.
I am doing the SimpleITK super build so itās building just about everything including ITK from scratch.
The Azure DevOps image seems to indicate that its running VS 16.0.3+28803.352: https://github.com/microsoft/azure-pipelines-image-generation/blob/master/images/win/Vs2019-Server2019-Readme.md
1 Like
Follow-up: Iāve tried with the latest version (16.1.5), and compilation still choke on some libs as described by @dzenanz (netlib, vnl_algo, etc). The /FS flag workaround works however.
2 Likes
See :
for a potential uniform method of addressing this problem from the ITK master branch.
2 Likes
Since PR1165 Visual Studio 2019 builds ITK without requiring any special settings.
1 Like
But we do need to be on ITK Master. When is the next release scheduled?
5.1.0 is scheduled for November. 5.0.2 for September. See the milestone list.
@matt.mccormick @blowekamp does it make sense to back-port PR1165 to 5.0.2? I assume that changes in parts of VXL which we use were minimal. @hjmjohnson can you confirm that?
1 Like
The changes to VXL necessary to make VS2019 work should be constrained to the main CMakeLists.txt file, and only a few isolated lines.
2 Likes
Is that going to be back ported to ITK 4.13.3(?)
The major issue I have now is that I have clients trying to compile our source codes with VS 2019 (probably with the default compilers) and ITK is failing to compile with no real way to get them out of the hole that they find themselves in.
The actual changes are super small, and should probably be easy to back-port them even to 4.13.3. But VXL underwent a major refactoring for ITKv5, including the build system, so I am not sure it is trivial.
OK, I will try back-porting this to 5.0.2 and 4.13.3.
2 Likes
I had been building SimpleITK (against ITKv4) in Release mode with VS2019 on Azure Pipelines OK. I believe that release mode was free of the debug symbol database bug. Recently a new compilation error started to occur with the following GDCM::
error C3848: expression having type 'const gdcm::dircos_comp' would lose some const-volatile qualifiers in order to call 'bool gdcm::dircos_comp::operator ()(const gdcm::dircos_key &,const gdcm::dircos_key &)'
I may look into back porting a fix to ITK 4.13 as well.
1 Like