Re: pg_receivewal.exe unhandled exception in zlib1.dll
От | Juan José Santamaría Flecha |
---|---|
Тема | Re: pg_receivewal.exe unhandled exception in zlib1.dll |
Дата | |
Msg-id | CAC+AXB0ROXu7z0OhzqtnMYMAORf3hPAuhUb609WCuC0k=O59zg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_receivewal.exe unhandled exception in zlib1.dll (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: pg_receivewal.exe unhandled exception in zlib1.dll
|
Список | pgsql-hackers |
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.
Regards,
Juan José Santamaría Flecha
В списке pgsql-hackers по дате отправления: