Unbundle windows

[zklaus]

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 @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Fixes #7

[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.

[zklaus]

@conda-forge-admin, please rerender

[hmaarrfk]

Don't you need to prefer external and for good measure remove the bundled sources all together?

[zklaus]

Don't you need to prefer external and for good measure remove the bundled sources all together?

Of course, thanks! I scanned the bld file and saw the PREFER_EXTERNAL lines but didn't read carefully enough to see that it was OFF 🤦.

[zklaus]

@conda-forge-admin, please rerender

[zklaus]

@conda-forge-admin, please rerender

[zklaus]

All seems to work except for three compatibility tests. That means that blosc2 fails to decompress the reference files for zlib compressed data that were created with the versions 1.3.0, 1.7.0, and 1.14.0. This may be due to the fact that zlib-ng is compiled in compatibility mode in case of the vendored copy, but not in the conda-forge version. If that is indeed the case, this would probably be an upstream bug.

[hmaarrfk]

I used to have this error, but it is because I had things poorly defined in my builds for external zlib Ng. You can look at my PR upstream recently made for clues on where to debug.

[zklaus]

Hm. Good to know. Do you mean Blosc/c-blosc2#393? Do you have any more pointers?

[hmaarrfk]

Blosc/c-blosc2#358 also

[hmaarrfk]

a breakthrough perhaps?

[zklaus]

Yeah, could be. Basically, it seems zlib-ng is aligned much closer with c-blosc than the original zlib in terms of types, i.e. it uses size_t and uint8_t and friends instead of the peculiar uLongf and similar. Now c-blosc, in its wrapper of the zlib functions, comes in with the right types for zlib-ng, but casts them to the original zlib types. For some reason, this fails on windows; I cannot say wether that is a genuine error, possibly because mscv by default uses llp64 instead of the lp64 that is common in Linux (see 64-bit data models), or some compiler quirk.

The difference with llp64 is that long is 32bit, but size_t is 64bit, whereas in lp64 both are 64bit.

In any case, it's probably a good idea to polish the patch and send it upstream.

[zklaus]

@conda-forge-admin, please rerender

[hmaarrfk]

Thank you, this is great!

[zklaus]

Thanks, @hmaarrfk! I have also pushed the patch upstream at Blosc/c-blosc2#402.

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!

[hmaarrfk]

Yes i noticed. Thanks for that!

[FrancescAlted]

Looks good!