Re: plperl on windows - Mailing list pgsql-hackers

From Andres Freund
Subject Re: plperl on windows
Date
Msg-id 20220130221659.tlyr2lbw3wk22owg@alap3.anarazel.de
Whole thread Raw
In response to Re: plperl on windows  (Andres Freund <andres@anarazel.de>)
Responses Re: plperl on windows
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: drop tablespace failed when location contains .. on win32
Next
From: Michael Banck
Date:
Subject: Re: CREATEROLE and role ownership hierarchies