Re: plperl on windows

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
Subject: Re: plperl on windows
Date: 2022-01-30 22:16:59
Message-ID: 20220130221659.tlyr2lbw3wk22owg@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-01-30 12:56:16 -0800, Andres Freund wrote:
> The gcc version has a Ilc_numeric_mutex_depth that the msvc version
> doesn't. The relevant part of intrpvar.h:
>
> PERLVAR(I, in_utf8_turkic_locale, bool)
> #if defined(USE_ITHREADS) && ! defined(USE_THREAD_SAFE_LOCALE)
> PERLVARI(I, lc_numeric_mutex_depth, int, 0) /* Emulate general semaphore */
> #endif
> PERLVARA(I, locale_utf8ness, 256, char)
>
> This conditional piece didn't yet exist in 5.26.n. Which is why that's the
> last version that actually works.
>
> USE_ITHREADS is defined in perls' config.h, but USE_THREAD_SAFE_LOCALE is
> derived from some other stuff. So that's the culprit.
>
>
> I gotta do something else for a bit, so I'll stop here for now.

The difference originates in this bit in plperl.h:

/* XXX The next few defines are unfortunately duplicated in makedef.pl, and
* changes here MUST also be made there */

# if ! defined(HAS_SETLOCALE) && defined(HAS_POSIX_2008_LOCALE)
# define USE_POSIX_2008_LOCALE
# ifndef USE_THREAD_SAFE_LOCALE
# define USE_THREAD_SAFE_LOCALE
# endif
/* If compiled with
* -DUSE_THREAD_SAFE_LOCALE, will do so even
* on unthreaded builds */
# elif (defined(USE_ITHREADS) || defined(USE_THREAD_SAFE_LOCALE)) \
&& ( defined(HAS_POSIX_2008_LOCALE) \
|| (defined(WIN32) && defined(_MSC_VER) && _MSC_VER >= 1400)) \
&& ! defined(NO_THREAD_SAFE_LOCALE)
# ifndef USE_THREAD_SAFE_LOCALE
# define USE_THREAD_SAFE_LOCALE
# endif
# ifdef HAS_POSIX_2008_LOCALE
# define USE_POSIX_2008_LOCALE
# endif
# endif
#endif

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?

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.

> 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.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2022-01-30 22:38:10 Re: CREATEROLE and role ownership hierarchies
Previous Message Tom Lane 2022-01-30 21:50:03 Re: drop tablespace failed when location contains .. on win32