Re: On non-Windows, hard depend on uselocale(3) - Mailing list pgsql-hackers
From | Masahiko Sawada |
---|---|
Subject | Re: On non-Windows, hard depend on uselocale(3) |
Date | |
Msg-id | CAD21AoBeHVsh6+UMSb-bbFFeTc4G1jOkBAvq-9BPMAuMoid3-A@mail.gmail.com Whole thread Raw |
In response to | Re: On non-Windows, hard depend on uselocale(3) (Peter Eisentraut <peter@eisentraut.org>) |
List | pgsql-hackers |
On Fri, Mar 28, 2025 at 9:32 AM Peter Eisentraut <peter@eisentraut.org> wrote: > > On 28.03.25 17:14, Masahiko Sawada wrote: > > On Fri, Mar 28, 2025 at 8:30 AM Peter Eisentraut <peter@eisentraut.org> wrote: > >> > >> On 09.02.25 08:32, Peter Eisentraut wrote: > >>> Checking the status of this thread ... > >>> > >>> The patches that removed the configure checks for _configthreadlocale(), > >>> and related cleanup, have been committed. > >>> > >>> The original patch to "Tidy up locale thread safety in ECPG library" is > >>> still outstanding. > >>> > >>> Attached is a rebased version, based on the posted v6, with a couple of > >>> small fixups from me. > >>> > >>> I haven't re-reviewed it yet, but from scanning the discussion, it looks > >>> close to done. > >> > >> After staring at this a few more times, I figured it was ready enough > >> and I committed it. > > > > It seems that some bf animals such as jackdaw are unhappy with this > > commit[0][1]. I also got the same 'undefined reference to symbol > > error' locally when building test_json_parser. > > Yeah, looks like we'll have to revert this for now. But I'm confused, > because I don't see any clear pattern for which platforms or > configurations it's failing and for which not. > Not sure it would help the investigation but I got the linker error when building with 'make' but not with 'meson'. Looking at the build logs, when building test_json_parser with meson, it adds -lpthread as follows: % /home/masahiko/work/gcc/12.2.0/bin/gcc -v -o src/test/modules/test_json_parser/test_json_parser_incremental_shlib src/test/modules/test_json_parser/test_json_parser_incremental_shlib.p/test_json_parser_incremental.c.o -Wl,--as-needed -Wl,--no-undefined '-Wl,-rpath,$ORIGIN/../../../interfaces/libpq:/lib/../lib64' -Wl,-rpath-link,/lib/../lib64 -Wl,-rpath-link,/home/masahiko/pgsql/source/dev_master/build/src/interfaces/libpq -Wl,--start-group src/common/libpgcommon_excluded_shlib.a src/common/libpgcommon_shlib.a src/common/libpgcommon_shlib_config_info.a src/common/libpgcommon_shlib_ryu.a src/port/libpgport_shlib.a src/interfaces/libpq/libpq.so.5.18 -lm -ldl -pthread -lrt /usr/lib64/libz.so /lib/../lib64/libzstd.so /usr/lib64/liblz4.so /usr/lib64/libssl.so /usr/lib64/libcrypto.so -Wl,--end-group whereas with 'make' it doesn't: % gcc -v -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -g -g -O0 test_json_parser_incremental.o -L../../../../src/port -L../../../../src/common -Wl,--as-needed -Wl,-rpath,'/home/masahiko/pgsql/master/lib',--enable-new-dtags -lpgcommon_excluded_shlib -L../../../../src/common -lpgcommon_shlib -L../../../../src/port -lpgport_shlib -L../../../../src/interfaces/libpq -lpq -o test_json_parser_incremental_shlib FYI the following change fixed the issue in my local env: --- a/src/test/modules/test_json_parser/Makefile +++ b/src/test/modules/test_json_parser/Makefile @@ -27,7 +27,7 @@ test_json_parser_incremental$(X): test_json_parser_incremental.o $(WIN32RES) $(CC) $(CFLAGS) $^ $(PG_LIBS_INTERNAL) $(LDFLAGS) $(LDFLAGS_EX) $(PG_LIBS) $(LIBS) -o $@ test_json_parser_incremental_shlib$(X): test_json_parser_incremental.o $(WIN32RES) - $(CC) $(CFLAGS) $^ $(LDFLAGS) -lpgcommon_excluded_shlib $(libpq_pgport_shlib) $(filter -lintl, $(LIBS)) -o $@ + $(CC) $(CFLAGS) $^ $(LDFLAGS) -lpgcommon_excluded_shlib $(libpq_pgport_shlib) $(filter -lintl, $(LIBS)) $(LIBS) -o $@ test_json_parser_perf$(X): test_json_parser_perf.o $(WIN32RES) $(CC) $(CFLAGS) $^ $(PG_LIBS_INTERNAL) $(LDFLAGS) $(LDFLAGS_EX) $(PG_LIBS) $(LIBS) -o $@ It seems that no MacOS and NetBSD animals failed due to this error because they have LC_C_LOCALE. But I'm not sure why some animals successfully built test_json_parser() even without -lpthread or -pthread[1][2]. Regards, [1] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=prion&dt=2025-03-28%2015%3A33%3A03&stg=make-testmodules [2] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=bushmaster&dt=2025-03-28%2015%3A32%3A01&stg=make-testmodules -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
pgsql-hackers by date: