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.
