Shared windows

[hmaarrfk]

Checklist

• [ ] Used a personal fork of the feedstock to propose changes
• [ ] Bumped the build number (if the version is unchanged)
• [ ] Reset the build number to 0 (if the version changed)
• [ ] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [ ] Ensured the license file is being packaged.

[conda-forge-webservices[bot]]

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.

[hmaarrfk]

@shockwave, @h-vetinari it seems to me that there might be some bugs in their CMake file that make certain symbols exposed via multiple libraries:

One example is: https://github.com/libjxl/libjxl/blob/f6d04b7655c6639d27cdf4c865c3a7fecf9cf268/lib/jxl_extras.cmake#L160

I'm somewhat worried about attempting to make a big cleanup, i've already failed once, my attempt here is to get the

• shared libraries built without the tools
• static libraries built with the tools. Install only the tools, no "extra" libraries.

[sshockwave]

I can live with building the shared libraries and the tools separately as long as we can revert it easily. I would like to keep the flexibility of testing whether future releases of libjxl have fixed this build issue.

That being said, I failed to dynamically build even only the core lib. I guess we have to link the internal libs statically and build the exposed libs dynamically. This would indeed require some changes to the CMake scripts.

libjxl_cms.lib             ---(static)---> libjxl.dll
libjxl.lib, libjxl_cms.lib ---(static)---> cjxl, djxl, and other tools

[sshockwave]

Fixed in #26