Linking errors with shared libraries with GradientDescentOptimizerv4Template symbols

[blowekamp]

I am getting linking errors on windows with shared libraries with this change. Linking error such as:

ITKOptimizersv4-5.3.lib(ITKOptimizersv4-5.3.dll) : error LNK2005: "protected: virtual __cdecl itk::GradientDescentOptimizerv4Template<double>::~GradientDescentOptimizerv4Template<double>(void)" (??1?$GradientDescentOptimizerv4Template@N@itk@@MEAA@XZ) already defined in sitkImageRegistrationMethod.obj [D:\a\1\bld\SimpleITK-build\Code\Registration\src\SimpleITKRegistration.vcxproj] [D:\a\1\bld\SimpleITK.vcxproj]

This is occurring because LBFGS2Optimizerv4 is a non-templated class and is compiled into the shared library. However, GradientDescentOptimizerv4Template is a template class as it linkage is specified as such, but it is being implicitly compiled and included in the ITKOptimizersv4 library as a side effect of being the parent class of LBFGS2Optimizerv4.

I have my doubt that it would be worth the trouble (likely cause other problem) to explicitly instantiate the GradientDescentOptimizerv4Template into the library. Are there other suggestions?

The PR #2372 is the origins of this issue.

[dzenanz]

Shouldn't identical duplicate template instantiations be ignored by the linker? How doesn't this problem arise in ITK's Python wrapping, which probably instantiates GradientDescentOptimizerv4Template?

[blowekamp]

Shouldn't identical duplicate template instantiations be ignored by the linker?

I think something like that happens on Linux and OS X, but not Windows which usually is more rigid with it's shared library symbols.

How doesn't this problem arise in ITK's Python wrapping, which probably instantiates GradientDescentOptimizerv4Template?

Does the ITK distributed binaries compile the ITK libraries as shared or static? I thought that one just one shared library (*.pyd) per ITK module?

[dzenanz]

I think they are compiled as shared libraries, by default one per module. Is SimpleITK different?

[blowekamp]

I think they are compiled as shared libraries, by default one per module.

With ITK python there are not ITK shared libraries (e.g. ITKOptimizersv4-5.3.dll ) there are only the loadable ITK python modules (*.pyd). The C++ ITK library is compile as static without the exports.

Is SimpleITK different?

Yes. SimpleITK has compiled C++ libraries which use ITK's compiled C++ libraries.

[dzenanz]

I don't have a suggested solution. Matt might have an opinion or a suggestion. I will ping him via email.

[blowekamp]

There are several parents in the hierarchy above the LBFGS2 Optimizer that are also templated. These would all need to be explicitly instantiate too which would be a bit of tedious work and refactoring. It may be best to make the LBFSG2 Optimizer a template and remove it from the compiled library.

While it would be a step backwards, reverting the change in parent class is an option too.

[dzenanz]

make the LBFSG2 Optimizer a template

This would be a backwards-incompatible change, right? Is SimpleITK compiled with legacy off? If so, your suggestion would work.

[thewtex]

Yes, a non-templated class inheriting from a template-class is going to be problematic for shared symbols.

It may be best to make the LBFSG2 Optimizer a template and remove it from the compiled library.

This seems reasonable.

[blowekamp]

Changing the base class as done in PR #2372 can be considered a backwards incompatible change.

Making LBFGS2 Optimizer a template would need to follow the same patter as done with the other optimizers. Some line similar to the following is used:

/** This helps to meet backward compatibility */
using GradientDescentOptimizerv4 = GradientDescentOptimizerv4Template<double>;

Where the original class name had the "Template" moniker added to the end, and an alias for the original class name.

[dzenanz]

Now I see that your suggested solution is not problematic at all. I guess that required change should be simpler than I thought too. Can you make a PR @blowekamp?