Found the following issues with the win32 & win64 releases when creating a NuGet package of zstd for use with librdkafka:
/SAFESEH:NO to the MSVC linker.I've created a NuGet package builder that uses the win32 & win64 release zips, it is usable with some minor caller hacks (such as mimicking the missing ZSTD_getErrorCode(), disable experimental options, ..).
NuGet package available here https://www.nuget.org/packages/confluent.libzstd.redist, but it is for experimental use only. (hint: NuGet packages are zip files with a .nupkg extension)
I intend to submit a PR with the NuGet builder, it would be great if the zstd project could maintain an official NuGet package.
I can pretty easily fix 1 and 2. I'll look into fixing points 3 and 4, but it might take me a while, since I'm not a Windows native. In the meantime, we build our Windows artifacts with Appveyor, so any PRs to our appveyor.yml are extremely welcome!
It looks like libzstd.dll exposes all the experimental symbols, but libzstd.lib doesn't (using nm). If you found that libzstd.dll doesn't export some symbol please let me know.
SAFESEH shows that it is MSVC specific, so MinGW doesn't have an equivalent flag. It would be a larger change to compile artifacts with MSVC, so I'm going to leave it for now (and keep this issue open).Re MinGW static / MSVC compatibility, this does not seem to be trivial to fix, and for my use-case linking the dynamic library is okay, since it is trivial to bundle the zstd lib with NuGet, hopefully this is a viable solution for other use-cases as well.
I think we can leave the static library as is for the time being.
Thank you!
Most helpful comment
I can pretty easily fix 1 and 2. I'll look into fixing points 3 and 4, but it might take me a while, since I'm not a Windows native. In the meantime, we build our Windows artifacts with Appveyor, so any PRs to our appveyor.yml are extremely welcome!