Windows libraries are statically linked

[hmaarrfk]

Comment:

This is probably why I was facing such a hard time with my recipe in

[h-vetinari]

See https://github.com/conda-forge/libjxl-split-feedstock/commit/06db486c11fba4fb78e26af8bbb18f5d7cdb4fe9, https://github.com/conda-forge/libjxl-split-feedstock/commit/0f9bca9f3e6832accf2c0f7d16891fbd9b57c283, resp this comment:

The library is temporarily changed to static build on Windows but will be fixed in the next release

@sshockwave has definitely tried! 😅

(though I only remember the notifications because I'm subscribed to this feedstock, didn't check the logs so don't know the reasons; if you run into troubles with re-enabling shared builds on windows, feel free to ping me and I'll try to help.)

[hmaarrfk]

ah yeah, i mean i couldn't get the tools to compile, so i know its hard.

i gave up on them.

The Cmake PUBLIC PRIVATE declarations of linkage are hard to follow.... i had to give up for the tooling.

[sshockwave]

I'm sorry for not getting back to you sooner. The error occurs since v0.9.0 refactors jxl_extra, jxl_cms, etc. into separate libraries. I recall that I managed to compile some of the versions locally with a LOT of patches, but eventually failed on CI. (See the long list of commits haha)

My guess on this problem is that .lib object are not generated if the DLL exports nothing. Windows requires explicit __declspec(dllexport) (seeJXL_EXPORT, JXL_CMS_EXPORT) for the symbol to be exported. The problem was partially fixed by https://github.com/libjxl/libjxl/pull/3083 but the problem still arises on other libs. Again, this is too much of a refactor and I'm hesitating whether it should take place in the patches or the upstream. The error logs seem different in https://github.com/conda-forge/libjxl-split-feedstock/pull/23 so reinvestigation might be needed.

[hmaarrfk]

Yeah. I saw your history and failed myself at making it a shared library. Thanks for confirming my suspicion

Mostly this is left here to denote future work that somebody can take on.

For many windows libraries. I find it hard for upstream developers to get the cmake files right. Given that many are interested in windows+pop workflows where static linking is encouraged no matter the platform, it is often hard for them to devote time to getting shared library builds right.