Build static win32 libs

[jschueller]

sundials_kinsol.dll doesn't export all of it's symbols when building assimulo package https://github.com/conda-forge/staged-recipes/pull/1727:

error LNK2019: unresolved external symbol _KINProcessError referenced in function _KINPinvSetJacFn

This switches from shared libs to static on win target (I tried providing both but the import and static libs names clash).

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[bjodah]

What do you mean by "import and static libs names clash"? Does the python extension module have the same name as the sundials provided shared library?

[jschueller]

The import lib and static lib of sundial.kinsol have the same name: sundial_kinsol.lib. As the shared lib is installed last it overwrites the static one.

[bjodah]

So it's an upstream problem in the CMake files in sundials really? Any chance of patching those?

[bjodah]

Sorry, I'm a bit lost in windows land, but aren't static libraries in windows named .lib and dynamic ones .dll? If so, how could there be a name clash?

[jschueller]

• On windows there are static libs (.lib), runtime dynamic libs (.dll) and also linktime import libs (.lib) which are created at the same time as the corresponding dll.
• I would recommend to not even allow to build static AND shared : client packages still have to detect the sundials libs, and only one can have the sundials_xx.lib name : we have to chose.

[bjodah]

Thank you for the explanation. I'm fine with using static libraries on windows if that simplifies things.

[bjodah]

Pinging @patricksnape who helped me get the recipe building on windows in the first place.

[bjodah]

Merging this, thanks @jschueller