On Sun, Jan 30, 2022 at 02:16:59PM -0800, Andres Freund wrote:
> Specifically where USE_THREAD_SAFE_LOCALE is defined for msvc. Which explains
> why the same perl build ends up with different definitions for
> PerlInterpreter, depending on headers getting compiled with gcc or
> msvc.
>
> Seems pretty clear that this is something that should be determined at build,
> rather than at #include time?
Agreed.
> I tested that just forcing the msvc build to behave the same using
> NO_THREAD_SAFE_LOCALE makes the tests pass. Yay. But it's obviously not a
> great solution - I'm not aware of a windows perl distribution that uses msvc,
> but who knows.
Last I looked (~2017), EDB distributed an MSVC-built Perl as the designated
Perl to use with https://www.postgresql.org/download/windows/ plperl.
> > The error message about mismatched lib / perl binary could really use a bit
> > more detail. It's pretty darn annoying to figure out right now what it could
> > mean.
>
> I wonder if we could do something to improve that on our side. This isn't the
> first time we've hunted down this kind of mismatch. It'd be much friendlier if
> we could get an error at build time, rather than runtime.
The MSVC build system does give a build-time error ("Perl test fails with or
without ...") for a Perl ABI mismatch. It would be a simple matter of
programming to have the configure+gmake build system do the same.