// Quick-fix to avoid link errors
```
Triggered Visual C++ compile errors:
> ITK\modules\thirdparty\vnl\src\vxl\v3p\netlib\laso/dnlaso.h(28): error C2144: syntax error: ‘char’ should be preceded by ‘)’
> ITK\modules\thirdparty\vnl\src\vxl\v3p\netlib\laso/dnlaso.h(28): error C2144: syntax error: ‘char’ should be preceded by ‘;’
> ITK\modules\thirdparty\vnl\src\vxl\v3p\netlib\laso/dnlaso.h(28): warning C4091: ‘’: ignored on left of ‘char’ when no variable is declared
This appears caused by a conflict between a _ **#define small char** _ in _C:\Program Files (x86)\Windows Kits\8.1\Include\shared\rpcndr.h_, and a function declaration in _ITK\modules\thirdparty\vnl\src\vxl\v3p\netlib\laso\dnlaso.h_:
```
extern int v3p_netlib_dnwla_(
....
v3p_netlib_logical *small, // Mind the 'small' identifier!!! -- Niels
v3p_netlib_logical *raritz,
v3p_netlib_doublereal *delta,
v3p_netlib_doublereal *eps,
v3p_netlib_integer *ierr
);
```
But clearly that’s unrelated to the original link errors.
---
### Author:  [@hjmjohnson](https://discourse.itk.org/u/hjmjohnson)
#### Post date: [September 3, 2018, 2:44pm UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/3 "2018-09-03T14:44:40Z")
Niels,
It is strange that your addition of pre-processor commands fixed a link error.
I’m having a very difficult time replicating the problem. Could you make an zip file with a CMakeLists.txt file and the source file that causes the problem? I’ve been unable to generate this issue.
Hans
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [September 3, 2018, 3:13pm UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/4 "2018-09-03T15:13:15Z")
Thanks for your reply, and your attempt to reproduce the link errors, @hjmjohnson Now I see, it was my own fault 🙄 My CMakeLists.txt did not link to all libraries from _${ITK\_LIBRARIES}_. Instead I just listed the subset of ITK lib files that **_I thought_** my project really needed:
```
target_link_libraries(MyProject
${ITK_LIB_DIR}/ITKCommon-5.0.lib
${ITK_LIB_DIR}/itkvnl-5.0.lib
${ITK_LIB_DIR}/itkvnl_algo-5.0.lib
${ITK_LIB_DIR}/itksys-5.0.lib
${ITK_LIB_DIR}/itkv3p_netlib-5.0.lib
${ITK_LIB_DIR}/itkvcl-5.0.lib
)
```
Apparently I should add _ITKVNLInstantiation-5.0.lib_, or just use _${ITK\_LIBRARIES}_! Either way, my link errors are gone now. 😀
---
### Author:  [@phcerdan](https://discourse.itk.org/u/phcerdan)
#### Post date: [September 3, 2018, 3:24pm UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/5 "2018-09-03T15:24:35Z")
For the future, if you just want a subset of ITK, point to the required modules using `COMPONENTS`, and then `${ITK_LIBRARIES}` will only contain this subset. For example:
```auto
find_package(ITK REQUIRED COMPONENTS
ITKCommon
ITKIOImageBase
ITKImageGrid
ITKImageIntensity
ITKImageStatistics
ITKImageIO
CONFIG
)
include(${ITK_USE_FILE})
target_link_libraries(Foo PUBLIC ${ITK_LIBRARIES})
```
You can check what modules a particular .cpp requires using [Utilities/Maintenance/WhatModulesITK.py](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Utilities/Maintenance/WhatModulesITK.py)
---
### Author:  [@hjmjohnson](https://discourse.itk.org/u/hjmjohnson)
#### Post date: [September 3, 2018, 3:24pm UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/6 "2018-09-03T15:24:23Z")
No problem! We’ve all been there.
Hans
---
### Author:  [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)
#### Post date: [September 3, 2018, 3:47pm UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/7 "2018-09-03T15:47:54Z")
> [@phcerdan](#):
>
> You can check what modules a particular .cpp requires using [Utilities/Maintenance/WhatModulesITK.py](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Utilities/Maintenance/WhatModulesITK.py)
Interesting! I’ll have a closer look.
But anyway, for the lime being I still maintain a list of those ITK lib files for my MeVisLab project, which is not using CMake (yet). MeVisLab uses Qt/QMake, instead of CMake, to create Visual Studio project files. Which means that I have to list the lib files in a QMake PRO file.
---
### Author:  [@simon.rit](https://discourse.itk.org/u/simon.rit)
#### Post date: [September 4, 2018, 10:49am UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/8 "2018-09-04T10:49:07Z")
The same commit caused link errors in the RTK code, see [RTK dashboard](http://my.cdash.org/index.php?project=RTK), e.g., [this build](https://my.cdash.org/viewBuildError.php?buildid=1515844). vnl\_svd\_fixed is indeed not instantiated for 1D registration, which we use in our code ([here](https://github.com/SimonRit/RTK/blob/master/include/rtkReg1DExtractShroudSignalImageFilter.hxx#L98)). Is this the expected behavior? If yes, should I instantiate the missing classes on RTK side?
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [September 5, 2018, 4:29pm UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/9 "2018-09-05T16:29:42Z")
@simon.rit based on your code, I added a test, reproduced the build errors, and fixed them in this patch:
[http://review.source.kitware.com/#/c/23687/](http://review.source.kitware.com/#/c/23687/)
---
### Author:  [@simon.rit](https://discourse.itk.org/u/simon.rit)
#### Post date: [September 6, 2018, 6:19am UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/10 "2018-09-06T06:19:54Z")
Thanks a lot, we are back to a clean [RTK dashboard](https://my.cdash.org/index.php?project=RTK). If I understand well, it seems that you are now favoring performances over genericity. Understandable but for the lambda user, should we explicitly state in the documentation or with macros which dimensions can be instantiated?
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [September 6, 2018, 2:37pm UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/11 "2018-09-06T14:37:48Z")
> [@simon.rit](#):
>
> Thanks a lot, we are back to a clean [RTK dashboard](https://my.cdash.org/index.php?project=RTK).
As a farmer I know would say,
> That’s a thing of friggin’ beauty.
> [@simon.rit](#):
>
> If I understand well, it seems that you are now favoring performances over genericity.
I think we strive to be both performant and generic.
> [@simon.rit](#):
>
> Understandable but for the lambda user, should we explicitly state in the documentation or with macros which dimensions can be instantiated?
Good idea 💡
Currently, any transform dimension should be supported in general, but only dimensions 1 to 9 are supported for transform IO.
>
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [September 6, 2018, 3:24pm UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/12 "2018-09-06T15:24:37Z")
There was a recent change in the itk::Transform classes which changed the VNL SVD computation from using dynamically sized arrays to fixed arrays. The fixed SVD changes was proposed as a WIP, but it got mixed up in the topic which had other significant performance enhancements for computing the Jacobian in the registration framework:
>
ITK’s VNL library configuration requires explicit instantiations for several types to use the fixed SVD:
> **[InsightSoftwareConsortium/ITK](https://github.com/InsightSoftwareConsortium/ITK/tree/master/Modules/ThirdParty/VNLInstantiation/src)**
>
> Insight Toolkit (ITK) -- Official Repository. Contribute to InsightSoftwareConsortium/ITK development by creating an account on GitHub.
These instances are not complete for 1-9, additionally there is the possibility to create transforms from N-\>M dimensions so the permutations need to be considered.
There are several other places in ITK which are using the dynamically sized SVD algorithm. This could use further investigation When this is done on a per pixel basis the dynamic allocation can be a significant scalability and performance bottleneck. ( When optimizing a filter/algorithm removing dynamic allocation in the inner loops is one of the first things to look at ). The broader use of fixed SVD in ITK could use further investigation.
A simular issue with itk::Matrix has occurred before:
>
With the current trend in ITK of trying to instantiate ITK for many types and dimensions for wrapping, the burden of having the code in headers only and not in compile object files is apparent. The bloated object files with duplicate compiled code is apparent. Explicitly instantiating code provide compile and binary size efficiency, so it is something we should strive to do more in ITK.
What are the options:
1. Instantiate more VNL types ( perhaps creating a macro to instantiate multiple classes as once )
2. Revet to the old dynamic SVD code, and not have the opportunity to use fixed SVD in ITK, but the SVD code in the Transform class is not used much.
3. Do some meta-programming one the transform dimensions if N \<= 5 && M==N then use fix SVD else use dynamic.
4. _updated_ Document that additional vnl headers should be included when the transform dimensions are not instantiated, however the current VNL instantiation are not in headers so library instantiated templates will be re instantiated.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [September 7, 2018, 6:19pm UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/13 "2018-09-07T18:19:29Z")
> [@blowekamp](#):
>
> Explicitly instantiating code provide compile and binary size efficiency, so it is something we should strive to do more in ITK.
While improved explicit instantiation support would help the build time and binary size of Python bindings and other large applications, we should not be striving, in general, for forced, explicit instantiation.
An optional explicit instantiation, as described here:
> [@extern templates to reduce build time](https://discourse.itk.org/t/extern-templates-to-reduce-build-time/1105):
>
> Hello, In OTB (which is heavily based on ITK) we have been looking at the possibility of introducing explicit instantiation of common template classes in the dynamic libraries we build, together with “extern template” declarations in headers to reduce build times significantly. A quick grep in ITK source shows that this C++11 feature is barely used in ITK, and it seems like it is for another purpose (dynamic\_cast issues). After a few test on our side, the best approach seems to be: In the he…
would be a nice feature.
More explicit instantiation increases build complexity, build times, and build size for common use cases. If an application is developed using templates, only the template instantiations that are used are compiled. You not need to compile and link instantiations that are not used.
In my ITK build, ` libITKTransformFactory-5.0.so.1` followed by `libitkvnl-5.0.so.1` are the largest libraries with a whopping 5.8 MB and 4.7 MB, respectively, even for an `-Os` / `MinSizeRel` build. In a real application, are both `float` and `double` transform’s of all different types for dimension 1-9 used? Rarely if ever.
In particular, it is **extremely important** that we do not build and link unused code when generating WebAssembly binaries. This impacts binary size, which is critical for WebAssembly. The `ITKCommon` and `itkvnl` libraries need to go on a diet for this use case. 🥫
> [@blowekamp](#):
>
> Do some meta-programming one the transform dimensions if N \<= 5 && M==N then use fix SVD else use dynamic.
An approach of fixed size implementations for common sizes and dynamic implementations for larger sizes provides a good balance of performance and binary size. Fixed sizes that are _always_ used could be explicitly instantiated.
Build errors related to `vnl_matrix_fixed` are also reported for ANTs here:
>
>
> This is what we needed for ANTs to build and link correctly. @ntustison FYI. … No urgency to merge.
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [September 28, 2018, 6:05pm UTC](https://discourse.itk.org/t/vnl-matrix-fixed-build-errors/1245/14 "2018-09-28T18:05:15Z")
[These](https://open.cdash.org/viewBuildError.php?buildid=5557632) build errors seems to be related. Can anyone confirm? Or fix?
**Edit** : this might be due to some CMake/Ninja hiccup. Let’s wait for tomorrow’s or Monday’s results.