On Tue, Feb 15, 2022 at 5:25 PM Andres Freund <andres@anarazel.de> wrote:
> If this is something we want to discard altogether, we can check at build > time with 'dumpbin' to ensure that all dlls share the same vcruntime.dll.
I think these days it's mostly a question of ucrtbase.dll vs ucrtbased.dll, right?
Either one would do the trick, just to tell apart 'debug' from 'release'.
FWIW, I've looked at using either vcpkg or conan to more easily install / build dependencies on windows, in the right debug / release mode.
The former was easier, but unfortunately the zlib, lz4, ... packages don't include the gzip, lz4 etc binaries right now. That might be easy enough to fix with an option. It does require building the dependencies locally.
Conan seemed to be a nicer architecture, but there's no builtin way to update to newer dependency versions, and non-versioned dependencies don't actually work. It has pre-built dependencies for the common cases.
I find that the repositories that are being currently proposed as a source for the Windows depencies [1], will lead to outdated or stale packages in many cases.
I have been testing vcpkg, and my only grievances have been that some packages were terribly slow to install and a couple were missing: Kerberos (but its own project seems to be active [2]) and ossp-uuid (which is to be expected).
I will have to do some testing with Conan and see how both compare.
