locale_table.h: new build-time errors #23464
Description
When building blead on two different platforms today, I observed lots of previously unseen build-time errors during make test_prep. Collecting and analyzing the output on FreeBSD-14, where the C-compiler is
$ clang --version
FreeBSD clang version 18.1.6
... I got:
$ report-build-warnings 434c9cd5f1.freebsd.threaded.maketp.output.txt.gz
File: 434c9cd5f1.freebsd.threaded.maketp.output.txt.gz
Wmacro-redefined 738
The individual warnings look like this:
[
{
char => 13,
group => "Wmacro-redefined",
line => 43,
source => "./locale_table.h",
text => "'LC_CTYPE_AVAIL_' macro redefined",
},
{
char => 13,
group => "Wmacro-redefined",
line => 60,
source => "./locale_table.h",
text => "'LC_NUMERIC_AVAIL_' macro redefined",
},
{
char => 13,
group => "Wmacro-redefined",
line => 81,
source => "./locale_table.h",
text => "'LC_COLLATE_AVAIL_' macro redefined",
},
{
char => 13,
group => "Wmacro-redefined",
line => 95,
source => "./locale_table.h",
text => "'LC_TIME_AVAIL_' macro redefined",
},
{
char => 13,
group => "Wmacro-redefined",
line => 109,
source => "./locale_table.h",
text => "'LC_MESSAGES_AVAIL_' macro redefined",
},
{
char => 13,
group => "Wmacro-redefined",
line => 123,
source => "./locale_table.h",
text => "'LC_MONETARY_AVAIL_' macro redefined",
},
{
char => 13,
group => "Wmacro-redefined",
line => 43,
source => "./locale_table.h",
text => "'LC_CTYPE_AVAIL_' macro redefined",
},
{
char => 13,
group => "Wmacro-redefined",
line => 60,
source => "./locale_table.h",
text => "'LC_NUMERIC_AVAIL_' macro redefined",
},
...
In context:
echo @`sh cflags "optimize='-O2 -pipe -fstack-protector-strong -fno-strict-aliasing'" opmini.o` -DPERL_IS_MINIPERL -DPERL_EXTERNAL_GLOB opmini.c
@cc -c -DPERL_CORE -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -DNO_POSIX_2008_LOCALE -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -std=c99 -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -Wall -Werror=pointer-arith -Werror=vla -Wextra -Wno-long-long -Wno-declaration-after-statement -Wc++-compat -Wwrite-strings -DPERL_IS_MINIPERL -DPERL_EXTERNAL_GLOB opmini.c
In file included from op.c:163:
In file included from ./perl.h:1218:
./locale_table.h:43:13: warning: 'LC_CTYPE_AVAIL_' macro redefined [-Wmacro-redefined]
43 | # define LC_CTYPE_AVAIL_ 1
| ^
./locale_table.h:38:13: note: previous definition is here
38 | # define LC_CTYPE_AVAIL_ 0
| ^
In file included from op.c:163:
In file included from ./perl.h:1218:
./locale_table.h:60:13: warning: 'LC_NUMERIC_AVAIL_' macro redefined [-Wmacro-redefined]
60 | # define LC_NUMERIC_AVAIL_ 1
| ^
./locale_table.h:55:13: note: previous definition is here
55 | # define LC_NUMERIC_AVAIL_ 0
| ^
In file included from op.c:163:
...
The format of these warnings is somewhat different on Debian Linux, where I'm compiling with gcc-12.2.0. I can supply more data upon request.
I haven't tried to formally identify the behavior-altering commit via bisection, but given the locations identified, I strongly suspect this recent commit:
commit 03e269a3672fae7697fd9cebd967b4d4ef6774c9
Author: Karl Williamson <khw@cpan.org>
AuthorDate: Fri Jul 11 10:42:41 2025 -0600
Commit: Karl Williamson <khw@cpan.org>
CommitDate: Tue Jul 22 09:52:18 2025 -0600
regen/locale.pl: Use 'USE_LOCALE" not 'NO_LOCALE'
NO_LOCALE is a Configure option used to override setting the internal
option USE_LOCALE. Internal checks should use the internal version.
Not doing this caused z/OS to think it should be using locales on
threaded systems, whereas it shouldn't.
FYI, the reason this is is that the OS refuses to change the locale at
all once a second thread is started. Perl relies on the ability to
change the locale at will to accommodate locales that have a comma be the
radix (decimal point) character and the huge amount of code that has
been written expecting that at all times a dot is the radix character.
This includes core code (which we could change) and XS code (which would
be overwhelming to change).
diff --git a/locale_table.h b/locale_table.h
...
@khwilliamson, can you take a look? Thanks.