Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. libpq: Authorize pthread_exit() in libpq_check

  2. Fix meson warning due to missing declaration of NM

  3. libpq: Refactor logic checking for exit() in shared library builds

  1. BUG #19095: Test if function exit() is used fail when linked static

    PG Bug reporting form <noreply@postgresql.org> — 2025-10-27T07:56:38Z

    The following bug has been logged on the website:

Bug reference:      19095
Logged by:          Torsten Rupp
Email address:      torsten.rupp@gmx.net
PostgreSQL version: 15.14
Operating system:   Linux
Description:        

Note: occur from version 15.14 or newer.

In src/interfaces/libpq/Makefile is a test if the function "exit()" (or in
general: a function exists with the name part "exit") is used:

libpq-refs-stamp: $(shlib)
ifneq ($(enable_coverage), yes)
ifeq (,$(filter aix solaris,$(PORTNAME)))
        @if nm -A -u $< 2>/dev/null | grep -v __cxa_atexit | grep exit; then
\
                echo 'libpq must not be calling any function which invokes
exit'; exit 1; \
        fi
endif
endif

This test fail if libpq is linked static to an application when e. g.
libcrypto is also linked static into libpq which add indirectly a call to
"pthread_exit()".

Possible fix: exclude pthread_exit(), too (like __cxa_atexit), e.g.:

libpq-refs-stamp: $(shlib)
ifneq ($(enable_coverage), yes)
ifeq (,$(filter aix solaris,$(PORTNAME)))
        @if nm -A -u $< 2>/dev/null | grep -v __cxa_atexit | grep -v
pthread_exit | grep exit; then \
                echo 'libpq must not be calling any function which invokes
exit'; exit 1; \
        fi
endif
endif

  2. Re: BUG #19095: Test if function exit() is used fail when linked static

    Michael Paquier <michael@paquier.xyz> — 2025-10-28T03:16:49Z

    On Mon, Oct 27, 2025 at 07:56:38AM +0000, PG Bug reporting form wrote:
> This test fail if libpq is linked static to an application when e. g.
> libcrypto is also linked static into libpq which add indirectly a call to
> "pthread_exit()".
> 
> Possible fix: exclude pthread_exit(), too (like __cxa_atexit), e.g.:

Previous discussions around this check:
- 936f56988741, with:
https://www.postgresql.org/message-id/CAEhC_BmNGKgj2wKArH2EAU11BsaHYgLnrRFJGRm5Vs8WJzyiQA@mail.gmail.com
- dc227eb82ea8, with:
https://www.postgresql.org/message-id/3128896.1624742969@sss.pgh.pa.us

We have usually used the buildfarm to decide how much restriction we
should put into this one, for good historical reasons because we
should never exit() directly from libpq, like this one:
https://www.postgresql.org/message-id/20210703001639.GB2374652@rfd.leadboat.com

Treating pthread_exit() as an exception sounds like it may be a good
thing anyway: we don't rely on it in the code core.

Now I am not completely sure how much we should care about considering
that any of that as something we need to tweak in the core code.  The
use of static libraries are usually discouraged, because it makes the
handling of package dependencies more complicated if some
sub-libraries need to be upgraded following a CVE-class issue, and
here you are pointing at what looks like a custom static library build
of libcrypto on Linux.

Opinions from others are welcome, mine counts like -0.5.
--
Michael

  3. Re: BUG #19095: Test if function exit() is used fail when linked static

    Torsten Rupp <torsten.rupp@gmx.net> — 2025-11-09T08:33:16Z

    Dear developers,

I opened this request for a behavior concerning functions with the name 
part "exit":

 > Bug reference:      19095
> Logged by:          Torsten Rupp
> Email address:      torsten.rupp@gmx.net
> PostgreSQL version: 15.14
> Operating system:   Linux
> Description:
> 
> Note: occur from version 15.14 or newer.
> 
> In src/interfaces/libpq/Makefile is a test if the function "exit()" (or in
> general: a function exists with the name part "exit") is used:
> 
> libpq-refs-stamp: $(shlib)
> ifneq ($(enable_coverage), yes)
> ifeq (,$(filter aix solaris,$(PORTNAME)))
>          @if nm -A -u $< 2>/dev/null | grep -v __cxa_atexit | grep exit; then
> \
>                  echo 'libpq must not be calling any function which invokes
> exit'; exit 1; \
>          fi
> endif
> endif
> 
> This test fail if libpq is linked static to an application when e. g.
> libcrypto is also linked static into libpq which add indirectly a call to
> "pthread_exit()".
> 
> Possible fix: exclude pthread_exit(), too (like __cxa_atexit), e.g.:
> 
> libpq-refs-stamp: $(shlib)
> ifneq ($(enable_coverage), yes)
> ifeq (,$(filter aix solaris,$(PORTNAME)))
>          @if nm -A -u $< 2>/dev/null | grep -v __cxa_atexit | grep -v
> pthread_exit | grep exit; then \
>                  echo 'libpq must not be calling any function which invokes
> exit'; exit 1; \
>          fi
> endif
> endif

BTW: if you wonder about static linkage: I'm aware of the disadvantages, 
but I use static linkage for a backup tool which should run e. g. in any 
live Linux from a USB medium, thus it should have as less dependencies 
to shared libraries as possible. A non-static version of the tool is 
also available. The issue does not occur with shared libraries, because 
then no function with the name part "exit" is linked into libpq.

Thank you for your attention.

Best regards, Torsten Rupp

  4. Re: BUG #19095: Test if function exit() is used fail when linked static

    BharatDB <bharatdbpg@gmail.com> — 2025-11-12T05:53:10Z

    >
>
> Hello Hackers,
>
> While reproducing a static linking issue between libpq and libcrypto.a,
> I observed that the Makefile's symbol check incorrectly reports missing
> exit() symbols because 'grep exit' also matches 'atexit' and
> 'OPENSSL_atexit', etc.
>
> As discussed in the thread by Michael Paquier
> (https://www.postgresql.org/message-id/aQA1obboZFjqjaBI%40paquier.xyz),
> it seems a related fix was committed earlier. However, I was able to
> reproduce this issue again using PostgreSQL 18 (latest release).
>
> Steps to reproduce:
>   nm -A -u ./src/interfaces/libpq/libpq.a
> /usr/lib/x86_64-linux-gnu/libcrypto.a 2>/dev/null | grep -v __cxa_atexit |
> grep exit
>
> Output:
>   /usr/lib/x86_64-linux-gnu/libcrypto.a:libcrypto-lib-init.o:
>     U atexit
>   /usr/lib/x86_64-linux-gnu/libcrypto.a:libdefault-lib-rand_unix.o:
>     U OPENSSL_atexit
>
> This falsely triggers an undefined exit() error.
> [1]Changing the grep pattern to match the exact symbol ('grep -x exit')
> prevents
> such false positives.

[2]Alternatively, excluding pthread_exit() (similar to
> __cxa_atexit) would also avoid the issue.
>
>   But [1] will handle all the false positives instead of just pthread_exit
.LGTM

Expected (after fix):
>   no output — no false positives.
>
> Patch attached.I would love to hear any suggestions from the committers.
>
  Thanks in advance

>
> Best regards,
> Vasuki M
>
    BharatDB,

> CDAC Chennai.
>

  5. Fwd: BUG #19095: Test if function exit() is used fail when linked static

    BharatDB <bharatdbpg@gmail.com> — 2025-11-12T05:54:31Z

    ---------- Forwarded message ---------
From: BharatDB <bharatdbpg@gmail.com>
Date: Wed, Nov 12, 2025 at 11:23 AM
Subject: Re: BUG #19095: Test if function exit() is used fail when linked
static
To: <torsten.rupp@gmx.net>, <pgsql-bugs@lists.postgresql.org>, <
michael@paquier.xyz>
Cc: VASUKI M <vasukim1992002@gmail.com>



> Hello Hackers,
>
> While reproducing a static linking issue between libpq and libcrypto.a,
> I observed that the Makefile's symbol check incorrectly reports missing
> exit() symbols because 'grep exit' also matches 'atexit' and
> 'OPENSSL_atexit', etc.
>
> As discussed in the thread by Michael Paquier
> (https://www.postgresql.org/message-id/aQA1obboZFjqjaBI%40paquier.xyz),
> it seems a related fix was committed earlier. However, I was able to
> reproduce this issue again using PostgreSQL 18 (latest release).
>
> Steps to reproduce:
>   nm -A -u ./src/interfaces/libpq/libpq.a
> /usr/lib/x86_64-linux-gnu/libcrypto.a 2>/dev/null | grep -v __cxa_atexit |
> grep exit
>
> Output:
>   /usr/lib/x86_64-linux-gnu/libcrypto.a:libcrypto-lib-init.o:
>     U atexit
>   /usr/lib/x86_64-linux-gnu/libcrypto.a:libdefault-lib-rand_unix.o:
>     U OPENSSL_atexit
>
> This falsely triggers an undefined exit() error.
> [1]Changing the grep pattern to match the exact symbol ('grep -x exit')
> prevents
> such false positives.

[2]Alternatively, excluding pthread_exit() (similar to
> __cxa_atexit) would also avoid the issue.
>
>   But [1] will handle all the false positives instead of just pthread_exit
.LGTM

Expected (after fix):
>   no output — no false positives.
>
> Patch attached.I would love to hear any suggestions from the committers.
>
  Thanks in advance

>
> Best regards,
> Vasuki M
>
    BharatDB,

> CDAC Chennai.
>

  6. Re: BUG #19095: Test if function exit() is used fail when linked static

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-11-12T06:38:47Z

    BharatDB <bharatdbpg@gmail.com> writes:
>> [1]Changing the grep pattern to match the exact symbol ('grep -x exit')
>> prevents such false positives.

We might as well remove the test entirely as do that; it would
fail to detect "_exit" for example.

Additionally, I don't have a lot of faith in "grep -x" being
universally portable.  POSIX 2018 does specify that switch, but
it mentions that it is "historically available only with fgrep".

Personally I'm okay with whitelisting pthread_exit() as
Torsten suggested.

BTW, it looks like libpq's meson.build is missing this check.

			regards, tom lane

  7. Re: BUG #19095: Test if function exit() is used fail when linked static

    Daniel Gustafsson <daniel@yesql.se> — 2025-11-12T08:13:09Z

    > On 12 Nov 2025, at 07:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Personally I'm okay with whitelisting pthread_exit() as
> Torsten suggested.

+1, we already have a few whitelisted entries and pthread_exit seems perfectly
reasonable to add to that list.

--
Daniel Gustafsson

  8. Re: BUG #19095: Test if function exit() is used fail when linked static

    Michael Paquier <michael@paquier.xyz> — 2025-11-12T08:15:15Z

    On Wed, Nov 12, 2025 at 09:13:09AM +0100, Daniel Gustafsson wrote:
> On 12 Nov 2025, at 07:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Personally I'm okay with whitelisting pthread_exit() as
>> Torsten suggested.
> 
> +1, we already have a few whitelisted entries and pthread_exit seems perfectly
> reasonable to add to that list.

WFM.
--
Michael

  9. Re: BUG #19095: Test if function exit() is used fail when linked static

    Daniel Gustafsson <daniel@yesql.se> — 2025-11-14T12:11:15Z

    > On 12 Nov 2025, at 09:15, Michael Paquier <michael@paquier.xyz> wrote:
> 
> On Wed, Nov 12, 2025 at 09:13:09AM +0100, Daniel Gustafsson wrote:
>> On 12 Nov 2025, at 07:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Personally I'm okay with whitelisting pthread_exit() as
>>> Torsten suggested.
>> 
>> +1, we already have a few whitelisted entries and pthread_exit seems perfectly
>> reasonable to add to that list.
> 
> WFM.

The attached trivial diff adds this to the whitelist clause in the Makefile.  I
experimented with adding this to Meson, and while it's trivial enough to do the
run_command with libpq_so.full_path, it's less clear to me exactly where in the
build it should be added.  I've pinged my colleague Bilal who is much better at
Meson than me to collaborate on that as a separate fix.

--
Daniel Gustafsson

  10. Re: BUG #19095: Test if function exit() is used fail when linked static

    Andres Freund <andres@anarazel.de> — 2025-11-14T14:01:06Z

    Hi,
On 2025-11-14 13:11:15 +0100, Daniel Gustafsson wrote:
> > On 12 Nov 2025, at 09:15, Michael Paquier <michael@paquier.xyz> wrote:
> > 
> > On Wed, Nov 12, 2025 at 09:13:09AM +0100, Daniel Gustafsson wrote:
> >> On 12 Nov 2025, at 07:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> Personally I'm okay with whitelisting pthread_exit() as
> >>> Torsten suggested.
> >> 
> >> +1, we already have a few whitelisted entries and pthread_exit seems perfectly
> >> reasonable to add to that list.
> > 
> > WFM.
> 
> The attached trivial diff adds this to the whitelist clause in the Makefile.  I
> experimented with adding this to Meson, and while it's trivial enough to do the
> run_command with libpq_so.full_path, it's less clear to me exactly where in the
> build it should be added.  I've pinged my colleague Bilal who is much better at
> Meson than me to collaborate on that as a separate fix.

For meson we'll have to filter where we test this more strictly - it'll
e.g. not work on windows, because there's no nm, perhaps no grep, etc.

But more generally: If we allow pthread_exit(), what's the point of this test?
That's one of the functions we better avoid calling, no?


ISTM that if we do want to continue having this test, the issue is that we're
testing the shared library - which will have already linked against static
libraries like the sanitizer ones or in this case libcrypto. What we ought to
do is to test the .o files constituting libpq.so, rather than the already
linked .so. That way we will find our own calls to exit etc, but not ones in
static libraries.

Greetings,

Andres Freund

  11. Re: BUG #19095: Test if function exit() is used fail when linked static

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-11-14T14:40:46Z

    Andres Freund <andres@anarazel.de> writes:
> But more generally: If we allow pthread_exit(), what's the point of this test?
> That's one of the functions we better avoid calling, no?

ATM it's not something we'd be tempted to call, but I take your point.

> ISTM that if we do want to continue having this test, the issue is that we're
> testing the shared library - which will have already linked against static
> libraries like the sanitizer ones or in this case libcrypto. What we ought to
> do is to test the .o files constituting libpq.so, rather than the already
> linked .so. That way we will find our own calls to exit etc, but not ones in
> static libraries.

My recollection is that that doesn't help as much as you'd think.
__tsan_func_exit, for one, can get injected into our own .o files
if we build with appropriate sanitizers enabled.

			regards, tom lane

  12. Re: BUG #19095: Test if function exit() is used fail when linked static

    BharatDB <bharatdbpg@gmail.com> — 2025-11-19T09:08:37Z

    Hi Andres and hackers,
I came up with the solution
— short follow-up with what I changed and how the Meson check actually runs.

Summary of what I did
  - Added a Meson custom_target in src/interfaces/libpq/meson.build that
    scans libpq's object files for direct exit() references.
  - Added pthread_exit to the Makefile whitelist (the Makefile test
    already existed; this just updates the whitelist).
  -Added the custom target in the top level meson.build

Where the Meson check lives and when it runs
  - I put the custom_target in src/interfaces/libpq/meson.build,
    immediately after the libpq shared/static library targets are
    defined and after the declare_dependency for libpq.  That is the
    correct location in the libpq build file.
  - The custom_target declares `depends: [libpq_st, libpq_so]`.  This
    is important: it tells Meson to build those targets first so the
    .o files are present in the build directory before the check runs.
    The check itself does not scan libpq_st or libpq_so; it scans
    files in build/src/interfaces/libpq/*.o.
  - The command uses `find <builddir>/src/interfaces/libpq -name '*.o'`
    and runs `nm -u` on each .o, piping through `grep -v` for the
    whitelisted names and finally checking for exit.
  - The check is skipped for:
      * cross-builds
      * when coverage (b_coverage) is enabled
      * on Windows (no nm/grep in the same form there) as Andrew questioned

Why pthread_exit is whitelisted
  - pthread_exit can legitimately appear in a few build/runtime
    configurations (thread runtimes or link-time glue), and the
    Makefile test was updated to whitelist it.  The Meson check has the
    same whitelist so both build systems behave the same.
  - Whitelisting pthread_exit doesn't remove the value of the test:
    it only avoids false positives for legitimate thread shutdown code.
    We still catch direct exit()/ _exit()/abort()-style calls as tom said.

How to reproduce locally
  - From repo root:
      rm -rf build
      meson setup build
      cd build
      ninja
    The custom_target runs as part of the normal build and will fail
    the build if any .o contains an un-whitelisted exit() reference.

On Fri, Nov 14, 2025 at 7:31 PM Andres Freund <andres@anarazel.de> wrote:

But more generally: If we allow pthread_exit(), what's the point of this
> test?
> That's one of the functions we better avoid calling, no?
>
 I agree it's worth questioning which functions we allow.  The
 current choice (whitelist pthread_exit) mirrors the Makefile
 behavior, avoids false positives, and keeps the test focused on
 direct process-termination calls authored in our code.  If the
 community prefers a stricter policy so we can adjust the whitelist.


> ISTM that if we do want to continue having this test, the issue is that
> we're
> testing the shared library - which will have already linked against static
> libraries like the sanitizer ones or in this case libcrypto. What we ought
> to
> do is to test the .o files constituting libpq.so, rather than the already
> linked .so. That way we will find our own calls to exit etc, but not ones
> in
> static libraries.
>

TBH After so many test runs I have finalized
Why scan .o files (not the final .so)?
  - A shared library is usually linked with other static libraries
    (libcrypto, sanitizer runtimes).  If we scan the final .so we'll
    see references that originate in those static libraries and produce
    false positives.
  - If we scan the .o files that make up libpq, we only inspect our
    own compilation units and will catch only exit() calls introduced
    by our code.

HTH! I attached the patch and also added the meson test output before
/after of any file containing an 'exit' explicitly; it fails the
build[ninja].

Regards,
Vasuki M
BharatDB[CDAC chennai]

  13. Re: BUG #19095: Test if function exit() is used fail when linked static

    BharatDB <bharatdbpg@gmail.com> — 2025-11-19T12:29:09Z

    Sorry,for the wrong patch this is the correct one.kindly find the attached
patch for testing
I would love to hear the feedback from you committers.

regards,
Vasuki M
BharatDB,C-DAC Chennai.

On Wed, Nov 19, 2025 at 2:38 PM BharatDB <bharatdbpg@gmail.com> wrote:

> Hi Andres and hackers,
> I came up with the solution
> — short follow-up with what I changed and how the Meson check actually
> runs.
>
> Summary of what I did
>   - Added a Meson custom_target in src/interfaces/libpq/meson.build that
>     scans libpq's object files for direct exit() references.
>   - Added pthread_exit to the Makefile whitelist (the Makefile test
>     already existed; this just updates the whitelist).
>   -Added the custom target in the top level meson.build
>
> Where the Meson check lives and when it runs
>   - I put the custom_target in src/interfaces/libpq/meson.build,
>     immediately after the libpq shared/static library targets are
>     defined and after the declare_dependency for libpq.  That is the
>     correct location in the libpq build file.
>   - The custom_target declares `depends: [libpq_st, libpq_so]`.  This
>     is important: it tells Meson to build those targets first so the
>     .o files are present in the build directory before the check runs.
>     The check itself does not scan libpq_st or libpq_so; it scans
>     files in build/src/interfaces/libpq/*.o.
>   - The command uses `find <builddir>/src/interfaces/libpq -name '*.o'`
>     and runs `nm -u` on each .o, piping through `grep -v` for the
>     whitelisted names and finally checking for exit.
>   - The check is skipped for:
>       * cross-builds
>       * when coverage (b_coverage) is enabled
>       * on Windows (no nm/grep in the same form there) as Andrew questioned
>
> Why pthread_exit is whitelisted
>   - pthread_exit can legitimately appear in a few build/runtime
>     configurations (thread runtimes or link-time glue), and the
>     Makefile test was updated to whitelist it.  The Meson check has the
>     same whitelist so both build systems behave the same.
>   - Whitelisting pthread_exit doesn't remove the value of the test:
>     it only avoids false positives for legitimate thread shutdown code.
>     We still catch direct exit()/ _exit()/abort()-style calls as tom said.
>
> How to reproduce locally
>   - From repo root:
>       rm -rf build
>       meson setup build
>       cd build
>       ninja
>     The custom_target runs as part of the normal build and will fail
>     the build if any .o contains an un-whitelisted exit() reference.
>
> On Fri, Nov 14, 2025 at 7:31 PM Andres Freund <andres@anarazel.de> wrote:
>
> But more generally: If we allow pthread_exit(), what's the point of this
>> test?
>> That's one of the functions we better avoid calling, no?
>>
>  I agree it's worth questioning which functions we allow.  The
>  current choice (whitelist pthread_exit) mirrors the Makefile
>  behavior, avoids false positives, and keeps the test focused on
>  direct process-termination calls authored in our code.  If the
>  community prefers a stricter policy so we can adjust the whitelist.
>
>
>> ISTM that if we do want to continue having this test, the issue is that
>> we're
>> testing the shared library - which will have already linked against static
>> libraries like the sanitizer ones or in this case libcrypto. What we
>> ought to
>> do is to test the .o files constituting libpq.so, rather than the already
>> linked .so. That way we will find our own calls to exit etc, but not ones
>> in
>> static libraries.
>>
>
> TBH After so many test runs I have finalized
> Why scan .o files (not the final .so)?
>   - A shared library is usually linked with other static libraries
>     (libcrypto, sanitizer runtimes).  If we scan the final .so we'll
>     see references that originate in those static libraries and produce
>     false positives.
>   - If we scan the .o files that make up libpq, we only inspect our
>     own compilation units and will catch only exit() calls introduced
>     by our code.
>
> HTH! I attached the patch and also added the meson test output before
> /after of any file containing an 'exit' explicitly; it fails the
> build[ninja].
>
> Regards,
> Vasuki M
> BharatDB[CDAC chennai]
>

  14. Re: BUG #19095: Test if function exit() is used fail when linked static

    Nazir Bilal Yavuz <byavuz81@gmail.com> — 2025-11-19T13:17:07Z

    Hi,

On Fri, 14 Nov 2025 at 15:11, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 12 Nov 2025, at 09:15, Michael Paquier <michael@paquier.xyz> wrote:
> >
> > On Wed, Nov 12, 2025 at 09:13:09AM +0100, Daniel Gustafsson wrote:
> >> On 12 Nov 2025, at 07:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> Personally I'm okay with whitelisting pthread_exit() as
> >>> Torsten suggested.
> >>
> >> +1, we already have a few whitelisted entries and pthread_exit seems perfectly
> >> reasonable to add to that list.
> >
> > WFM.
>
> The attached trivial diff adds this to the whitelist clause in the Makefile.  I
> experimented with adding this to Meson, and while it's trivial enough to do the
> run_command with libpq_so.full_path, it's less clear to me exactly where in the
> build it should be added.  I've pinged my colleague Bilal who is much better at
> Meson than me to collaborate on that as a separate fix.

Sorry for the late reply. I replaced the Makefile portion with the
Perl script, so that it can be used for both meson and autoconf build
systems. The script takes two arguments

- input_file -> path of library file.
- stamp_file -> to create a stamp file for the meson build, so that
meson does not run while the library file is not changed. Autoconf
build does not use this option.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

  15. Re: BUG #19095: Test if function exit() is used fail when linked static

    Nazir Bilal Yavuz <byavuz81@gmail.com> — 2025-11-24T11:04:01Z

    Hi,

On Wed, 19 Nov 2025 at 16:17, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
>
> Sorry for the late reply. I replaced the Makefile portion with the
> Perl script, so that it can be used for both meson and autoconf build
> systems.

Apparently we do not need to remove the stamp-file in the perl script,
meson already handles that internally. v2 is attached.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

  16. Re: BUG #19095: Test if function exit() is used fail when linked static

    Michael Paquier <michael@paquier.xyz> — 2025-11-24T21:43:43Z

    On Mon, Nov 24, 2025 at 02:04:01PM +0300, Nazir Bilal Yavuz wrote:
> Apparently we do not need to remove the stamp-file in the perl script,
> meson already handles that internally. v2 is attached.

Good idea to embed that in a perl script!

> +# Check for functions that libpq must not call, currently just exit().
> +# (Ideally we'd reject abort() too, but there are various scenarios where
> +# build toolchains insert abort() calls, e.g. to implement assert().)
> +# If nm doesn't exist or doesn't work on shlibs, this test will do nothing,
> +# which is fine.  The exclusion of __cxa_atexit is necessary on OpenBSD,
> +# which seems to insert references to that even in pure C code. Excluding
> +# __tsan_func_exit is necessary when using ThreadSanitizer data race detector
> +# which use this function for instrumentation of function exit.
> +# Skip the test when profiling, as gcc may insert exit() calls for that.
> +# Also skip the test on platforms where libpq infrastructure may be provided
> +# by statically-linked libraries, as we can't expect them to honor this
> +# coding rule.

Including a reference to "nm" in this comment for meson is definitely
fine, because it is used as a pre-check in this code with
find_program.  However, shouldn't we document the platform-specific
exclusions in the perl script itself?  As of the patch, the
explanation is a copy-paste of src/interfaces/libpq/Makefile.  I think
that we'd better group everything together, rather than have the same
contents explained in two places.  Perhaps I would add an extra
comment in meson.build and the Makefile to document that all the
platform-relevant details are in the perl script itself.

I would be also tempted to move the solaris check inside the perl
script rather than have it duplicated across meson and make, then do
something based on $Config{osname} instead.
--
Michael

  17. Re: BUG #19095: Test if function exit() is used fail when linked static

    VASUKI M <vasukim1992002@gmail.com> — 2025-11-25T09:11:32Z

    On Tue, 25 Nov 2025 at 03:14, Michael Paquier <michael@paquier.xyz> wrote:

> Including a reference to "nm" in this comment for meson is definitely
> fine, because it is used as a pre-check in this code with
> find_program.  However, shouldn't we document the platform-specific
> exclusions in the perl script itself?  As of the patch, the
> explanation is a copy-paste of src/interfaces/libpq/Makefile.  I think
> that we'd better group everything together, rather than have the same
> contents explained in two places.  Perhaps I would add an extra
> comment in meson.build and the Makefile to document that all the
> platform-relevant details are in the perl script itself.
>
> Thanks for this suggestion michael & Nazir for the code,i have made the
changes you said

Also added the check where it scans for nm in the environment if it is not
present then it gracefully skips the test.
V3 attached kindly check and review it.


> I would be also tempted to move the solaris check inside the perl
> script rather than have it duplicated across meson and make, then do
> something based on $Config{osname} instead.
>
Done

Testing performed:
  - Built with both autoconf+Makefile and Meson builds.
  - Verified the script runs inside Meson via the custom_target and
    confirmed with ninja -v.
>grep -R "libpq-exit-check" build.ninja
build src/interfaces/libpq/libpq-refs-stamp: CUSTOM_COMMAND
src/interfaces/libpq/libpq.so.5.19 |
../src/interfaces/libpq/libpq-exit-check /usr/bin/perl
 COMMAND = /usr/bin/perl ../src/interfaces/libpq/libpq-exit-check
--input_file src/interfaces/libpq/libpq.so.5.19 --stamp_file
src/interfaces/libpq/libpq-refs-stamp
 description = Generating$ src/interfaces/libpq/libpq-exit-check$ with$ a$
custom$ command

  - Injected a fake exit() reference into fe-connect.c and ensured the
    build fails with the expected error message.
  - Confirmed that removing nm causes the script to skip the check cleanly.
  - Verified that Meson’s stamp file prevents re-running the check when
    libpq.so has not changed.

Regards,
Vasuki M
CDAC-Chennai

  18. Re: BUG #19095: Test if function exit() is used fail when linked static

    Nazir Bilal Yavuz <byavuz81@gmail.com> — 2025-11-25T10:07:24Z

    Hi,

On Tue, 25 Nov 2025 at 12:11, VASUKI M <vasukim1992002@gmail.com> wrote:
>
> On Tue, 25 Nov 2025 at 03:14, Michael Paquier <michael@paquier.xyz> wrote:
>>
>> Including a reference to "nm" in this comment for meson is definitely
>> fine, because it is used as a pre-check in this code with
>> find_program.  However, shouldn't we document the platform-specific
>> exclusions in the perl script itself?  As of the patch, the
>> explanation is a copy-paste of src/interfaces/libpq/Makefile.  I think
>> that we'd better group everything together, rather than have the same
>> contents explained in two places.  Perhaps I would add an extra
>> comment in meson.build and the Makefile to document that all the
>> platform-relevant details are in the perl script itself.
>>
> Thanks for this suggestion michael & Nazir for the code,i have made the changes you said
>
> Also added the check where it scans for nm in the environment if it is not present then it gracefully skips the test.
> V3 attached kindly check and review it.

Thank you for working on this!

diff --git a/src/interfaces/libpq/Makefile b/src/interfaces/libpq/Makefile
index da66500..305361f 100644
--- a/src/interfaces/libpq/Makefile
+++ b/src/interfaces/libpq/Makefile

-ifeq (,$(filter solaris,$(PORTNAME)))
-    @if nm -A -u $< 2>/dev/null | grep -v -e __cxa_atexit -e
__tsan_func_exit | grep exit; then \
-        echo 'libpq must not be calling any function which invokes
exit'; exit 1; \
-    fi
+    # See libpq-exit-check for full platform rules and whitelisting.
+    $(PERL) libpq-exit-check --input_file $<
 endif
-endif
-    touch $@
+    touch $@

There are unnecessary indentation changes.

diff --git a/src/interfaces/libpq/libpq-exit-check
b/src/interfaces/libpq/libpq-exit-check
new file mode 100755
index 0000000..f500cef
--- /dev/null
+++ b/src/interfaces/libpq/libpq-exit-check

I would prefer more in-line comments instead of the comment at the top
but I think this is a preference.

diff --git a/src/interfaces/libpq/meson.build b/src/interfaces/libpq/meson.build
index a74e885..1b32eed 100644
--- a/src/interfaces/libpq/meson.build
+++ b/src/interfaces/libpq/meson.build

+if find_program('nm', required: false, native: true).found() and not
get_option('b_coverage')

I would delete the 'nm' check there, since we have the same check in
the PERL script. This makes the meson.build and the Makefile more
similar.

Also, I would change the comment at the Makefile and the meson.build
with the comment below, otherwise we lose information:

# Check for functions that libpq must not call, currently just exit().
# (Ideally we'd reject abort() too, but there are various scenarios where
# build toolchains insert abort() calls, e.g. to implement assert().)
# Skip the test when profiling, as gcc may insert exit() calls for that.

Nitpick: I suggest running pgperltidy [1] on the libq-exit-check PERL file.

[1] https://github.com/postgres/postgres/blob/master/src/tools/pgindent/pgperltidy

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

  19. Re: BUG #19095: Test if function exit() is used fail when linked static

    Daniel Gustafsson <daniel@yesql.se> — 2025-11-25T10:51:55Z

    > On 25 Nov 2025, at 10:11, VASUKI M <vasukim1992002@gmail.com> wrote:

> Thanks for this suggestion michael & Nazir for the code,i have made the changes you said 
> 
> Also added the check where it scans for nm in the environment if it is not present then it gracefully skips the test.

+if find_program('nm', required: false, native: true).found() and not get_option('b_coverage')
Sorry for being late to the party, but I wonder why we aren't adding this check
to the toplevel meson.build and configure.ac (via config/programs.m4) like how
we check for all others tools used by the build?  Such checks should of course
not fail the configuration, merely record the presence or absence of the tool.
The path can then be exported to src/interfaces/libpq/{Makefile|meson.build} to
use.


+open my $fh, '-|', "$nm_path -A -u $input_file 2>/dev/null"
This filehandle is never closed.


+# ---- Skip entirely on Solaris ----
+if ($Config{osname} =~ /solaris/i) {
+    exit 0;
+}
This won't work on Windows either, which wasn't checked for in the Makefile
since make isn't used on Windows.

--
Daniel Gustafsson

  20. Re: BUG #19095: Test if function exit() is used fail when linked static

    Michael Paquier <michael@paquier.xyz> — 2025-11-26T03:43:01Z

    On Tue, Nov 25, 2025 at 11:51:55AM +0100, Daniel Gustafsson wrote:
> +if find_program('nm', required: false, native: true).found() and not get_option('b_coverage')
> Sorry for being late to the party, but I wonder why we aren't adding this check
> to the toplevel meson.build and configure.ac (via config/programs.m4) like how
> we check for all others tools used by the build?  Such checks should of course
> not fail the configuration, merely record the presence or absence of the tool.
> The path can then be exported to src/interfaces/libpq/{Makefile|meson.build} to
> use.

+1 for this find_program() call grouped at the top of meson.build,
grouped with the others.
--
Michael

  21. Re: BUG #19095: Test if function exit() is used fail when linked static

    VASUKI M <vasukim1992002@gmail.com> — 2025-12-01T04:57:38Z

    Hi Daniel, Michael,Nazir

Thanks for the feedback.

For v4 I will implement the approach you outlined:

  -Move the nm detection to the top-level build:
      - Add find_program('nm') in the root meson.build
      - Add PGAC_CHECK_PROG(NM_PROG, nm) in configure.ac
    and export the result down into src/interfaces/libpq for use by both
    Meson and Makefile builds.

  -Pass the resolved nm path into libpq-exit-check via a --nm argument,
    removing the internal which nm lookup from the script.

  -Expand the platform skip logic in the script to include Windows in
    addition to Solaris, and close the filehandle as suggested.

  -Replace the comments in Makefile and meson.build with the unified
    explanatory block, and keep all platform details inside the script.

I will post v4 with these changes shortly.

Regards,
Vasuki

On Wed, 26 Nov 2025 at 09:13, Michael Paquier <michael@paquier.xyz> wrote:

> On Tue, Nov 25, 2025 at 11:51:55AM +0100, Daniel Gustafsson wrote:
> > +if find_program('nm', required: false, native: true).found() and not
> get_option('b_coverage')
> > Sorry for being late to the party, but I wonder why we aren't adding
> this check
> > to the toplevel meson.build and configure.ac (via config/programs.m4)
> like how
> > we check for all others tools used by the build?  Such checks should of
> course
> > not fail the configuration, merely record the presence or absence of the
> tool.
> > The path can then be exported to
> src/interfaces/libpq/{Makefile|meson.build} to
> > use.
>
> +1 for this find_program() call grouped at the top of meson.build,
> grouped with the others.
> --
> Michael
>

  22. Re: BUG #19095: Test if function exit() is used fail when linked static

    VASUKI M <vasukim1992002@gmail.com> — 2025-12-03T11:59:33Z

    Hi Hackers,

This is a refreshed version of the patch to unify the exit() reference check
performed during libpq builds. Earlier versions had duplicated logic between
the Makefile and Meson builds, while platform-specific details were also
split
between comments and build rules.

Following feedback from Michael, Daniel, Tom, and Nazir, v4 includes the
following changes:
Changes in v4

   -

   Added top-level AC_PATH_PROG(NM, nm) in configure.ac, and propagated
   it via NM, so both build systems use the same nm path.
   -

   Updated Makefile and Meson rules to invoke the new Perl helper using
   -

   - -nm=$(NM) / - -nm=@NM@
   -

   Centralized all platform-specific behavior in the Perl script:
   -

      Skip on Solaris and Windows
      -

      Handle ThreadSanitizer (__tsan_func_exit)
      -

      Handle OpenBSD’s __cxa_atexit
      -

      Whitelist pthread_exit()
      -

      Gracefully skip if nm is not available
      -

   Removed redundant checks from meson.build and Makefile and replaced them
   with
   a short reference to the script.
   -

   Added missing cleanup (closing filehandle), and improved comments.
   -

   Ensured consistent behavior across autoconf and Meson builds.

Testing:

Both autoconf and Meson builds were tested with:

   -

   Valid nm present
   -

   Missing nm
   -

   Solaris/Windows-skip behavior
   -

   Injected exit() symbol to confirm failure mode works correctly

The behavior is now uniform across build systems.

Patch is attached.

Thanks for the reviews so far, and I welcome further comments.

Regards,
Vasuki

>
> On Wed, 26 Nov 2025 at 09:13, Michael Paquier <michael@paquier.xyz> wrote:
>
>> On Tue, Nov 25, 2025 at 11:51:55AM +0100, Daniel Gustafsson wrote:
>> > +if find_program('nm', required: false, native: true).found() and not
>> get_option('b_coverage')
>> > Sorry for being late to the party, but I wonder why we aren't adding
>> this check
>> > to the toplevel meson.build and configure.ac (via config/programs.m4)
>> like how
>> > we check for all others tools used by the build?  Such checks should of
>> course
>> > not fail the configuration, merely record the presence or absence of
>> the tool.
>> > The path can then be exported to
>> src/interfaces/libpq/{Makefile|meson.build} to
>> > use.
>>
>> +1 for this find_program() call grouped at the top of meson.build,
>> grouped with the others.
>>
> Fixed in the v4 please review it.

> --
>> Michael
>>
>

  23. Re: BUG #19095: Test if function exit() is used fail when linked static

    Daniel Gustafsson <daniel@yesql.se> — 2025-12-03T23:33:55Z

    > On 3 Dec 2025, at 12:59, VASUKI M <vasukim1992002@gmail.com> wrote:

> This is a refreshed version of the patch to unify the exit() reference check
> performed during libpq builds. Earlier versions had duplicated logic between
> the Makefile and Meson builds, while platform-specific details were also split
> between comments and build rules.

Thanks for the update.  This patch builds on previous patches posted in the
thread which makes it more complicated to review.  Can you please post a full
squashed patch against master so we can be absolutely sure we are looking at
the tree in the same state that you are.

--
Daniel Gustafsson

  24. Re: BUG #19095: Test if function exit() is used fail when linked static

    Michael Paquier <michael@paquier.xyz> — 2025-12-04T00:32:03Z

    On Thu, Dec 04, 2025 at 12:33:55AM +0100, Daniel Gustafsson wrote:
> Thanks for the update.  This patch builds on previous patches posted in the
> thread which makes it more complicated to review.  Can you please post a full
> squashed patch against master so we can be absolutely sure we are looking at
> the tree in the same state that you are.

Yeah, I was just playing with this patch a little bit this morning,
and reworked it as the attached, adjusting a bunch of stuff inside it.
The main complaint that I have with v4 is the fact that the new check
for pthread_exit() was not split as a patch of its own, being hidden
in the perl script introduced.

Saying that, passing the path of nm as argument to the perl script is
something that feels OK here, as does the coverage check added twice
for meson and Makefile, rather than relying on enable_coverage in an
ENV.  Feel free to comment on these points, of course.

There were a few other things (comments, etc.) that I have tweaked
(commit message not edited, stolen from v4), but feel free to see the
attached for all the details.  libpq fails properly after planting
some exit() calls reported by nm.  I have run once autoreconf while on
it, before running a check in the CI, which was also OK.
--
Michael

  25. Re: BUG #19095: Test if function exit() is used fail when linked static

    VASUKI M <vasukim1992002@gmail.com> — 2025-12-04T11:08:40Z

    Hi all,
I am back with the changes in v6,

On Thu, 4 Dec 2025 at 06:02, Michael Paquier <michael@paquier.xyz> wrote:

> On Thu, Dec 04, 2025 at 12:33:55AM +0100, Daniel Gustafsson wrote:
> > Thanks for the update.  This patch builds on previous patches posted in
> the
> > thread which makes it more complicated to review.  Can you please post a
> full
> > squashed patch against master so we can be absolutely sure we are
> looking at
> > the tree in the same state that you are.


This v6 series is squashed and rebased on the current master. It also
includes the revisions and clarifications suggested in the previous round
of review, including Michael’s comments.


> Yeah, I was just playing with this patch a little bit this morning,
> and reworked it as the attached, adjusting a bunch of stuff inside it.
> The main complaint that I have with v4 is the fact that the new check
> for pthread_exit() was not split as a patch of its own, being hidden
> in the perl script introduced.
>

First of all,thanks for testing the patch.
Sorry for the inconvenience ,here I have attached separate patches for
libpq-exit-check and whitelisting of pthread_exit().

In Michael’s v5 1/2 patch, the configure file had changes because it was
generated after running autoreconf.Is it correct to include generated files
in the patches (such as configure,configure.status or other auto-generated
files).
Or only the change in configure.ac should be part of the patch.

Saying that, passing the path of nm as argument to the perl script is
> something that feels OK here, as does the coverage check added twice
> for meson and Makefile, rather than relying on enable_coverage in an
> ENV.  Feel free to comment on these points, of course.
>

I agree with the approach of keeping the coverage
condition local to each build system rather than relying on
enable_coverage  as
an environment variable. In practice, autoconf (enable_coverage) and Meson
(b_coverage) expose their coverage settings independently, so duplicating
the
check avoids any accidental cross-build inconsistencies. It also prevents
the
script from having to detect build-system-specific flags internally, keeping
libpq-check.pl focused only on symbol inspection. So I think it makes sense
for Makefile and Meson to each guard their own invocation. What do you
think?

I welcome any additional suggestions regarding the comments or the code.

Regards,
Vasuki M

  26. Re: BUG #19095: Test if function exit() is used fail when linked static

    Michael Paquier <michael@paquier.xyz> — 2025-12-05T00:41:21Z

    On Thu, Dec 04, 2025 at 04:38:40PM +0530, VASUKI M wrote:
> This v6 series is squashed and rebased on the current master. It also
> includes the revisions and clarifications suggested in the previous round
> of review, including Michael’s comments.

Including the changes in ./configure is not mandatory for patch
authors, as this is something that committers take care of.  Still,
these are useful for the CI and testing the ./configure code.

> I agree with the approach of keeping the coverage
> condition local to each build system rather than relying on
> enable_coverage  as
> an environment variable. In practice, autoconf (enable_coverage) and Meson
> (b_coverage) expose their coverage settings independently, so duplicating
> the
> check avoids any accidental cross-build inconsistencies. It also prevents
> the
> script from having to detect build-system-specific flags internally, keeping
> libpq-check.pl focused only on symbol inspection. So I think it makes sense
> for Makefile and Meson to each guard their own invocation. What do you
> think?

The only differences I can see between v5 and v6 is that the perl
script uses whitespaces for its code indentation rather than tabs,
which I guess is not expected.  Most of the diffs between v6 and v5 go
away once a perl indentation is applied.

I am not going to take a bet on this one on a Friday, so let's give it
a few more days.  Have others any comments and/or concerns?
--
Michael

  27. Re: BUG #19095: Test if function exit() is used fail when linked static

    VASUKI M <vasukim1992002@gmail.com> — 2025-12-08T04:41:08Z

    Hi Michael,

Thanks for checking the v6 patch.

Regarding the whitespace comment - I had already ran the pgperltidy on the
perl
script libpq-check.pl before  sending the patch,and I also verified the tab
indentation
with cat -T  to ensure the tabs were being used.FS,The current version of
the scripts in
v6 should already follow the standard pgindent/pgperltidy formatting

If there is still any specific section that appears mis-indented on your
side,
please let me know and I will adjust it.

cdac@cdac-Aspire-Lite-AL15-41:~/pg-libpq$ src/tools/pgindent/pgperltidy
src/interfaces/libpq/libpq-check.pl

cdac@cdac-Aspire-Lite-AL15-41:~/pg-libpq$

cdac@cdac-Aspire-Lite-AL15-41:~/pg-libpq$ cat -T src/interfaces/libpq/
libpq-check.pl
#!/usr/bin/perl
#
# src/interfaces/libpq/libpq-check.pl
#
# Copyright (c) 2025, PostgreSQL Global Development Group
#
# Check that the state of a libpq library.  Currently, this script checks
# that exit() is not called, because client libraries must not terminate
# the host application.
#
# This script is called by both Makefile and Meson.

use strict;
use warnings FATAL => 'all';

use Getopt::Long;
use Config;

my $nm_path;
my $input_file;
my $stamp_file;
my @problematic_lines;

Getopt::Long::GetOptions(
^I'nm:s' => \$nm_path,
^I'input_file:s' => \$input_file,
^I'stamp_file:s' => \$stamp_file) or die "$0: wrong arguments\n";

die "$0: --input_file must be specified\n" unless defined $input_file;
die "$0: --nm must be specified\n" unless defined $nm_path and -x $nm_path;

sub create_stamp_file
{
^Iif (!(-f $stamp_file))
^I{
^I^Iopen my $fh, '>', $stamp_file
^I^I  or die "can't open $stamp_file: $!";
^I^Iclose $fh;
^I}
}

# ---- Skip on Windows and Solaris ----
if (   $Config{osname} =~ /MSWin32|cygwin|msys/i
^I|| $Config{osname} =~ /solaris/i)
{
^Iexit 0;
}

# Run nm to scan for symbols.  If nm fails at runtime, skip the check.
open my $fh, '-|', "$nm_path -A -u $input_file 2>/dev/null"
  or exit 0;

while (<$fh>)
{

^I# Set of symbols allowed:
^I#     __cxa_atexit     - injected by some libcs (e.g., OpenBSD)
^I#     __tsan_func_exit - ThreadSanitizer instrumentation
^I#     pthread_exit     - legitimate thread cleanup

^Inext if /__cxa_atexit/;
^Inext if /__tsan_func_exit/;
^Inext if /pthread_exit/;

^I# Anything containing "exit" is suspicious.
^I# (Ideally we should reject abort() too, but there are various scenarios
^I# where build toolchains insert abort() calls, e.g. to implement
assert().)
^Iif (/exit/)
^I{
^I^Ipush @problematic_lines, $_;
^I}
}
close $fh;

if (@problematic_lines)
{
^Iprint "libpq must not be calling any function which invokes exit\n";
^Iprint "Problematic symbol references:\n";
^Iprint @problematic_lines;

^Iexit 1;
}

# Create stamp file, if required
if (defined($stamp_file))
{
^Icreate_stamp_file();
}

exit 0;
cdac@cdac-Aspire-Lite-AL15-41:~/pg-libpq$

Regards,

Vasuki

  28. Re: BUG #19095: Test if function exit() is used fail when linked static

    Michael Paquier <michael@paquier.xyz> — 2025-12-09T04:16:32Z

    On Mon, Dec 08, 2025 at 10:11:08AM +0530, VASUKI M wrote:
> Regarding the whitespace comment - I had already ran the pgperltidy on the
> perl script libpq-check.pl before  sending the patch,and I also verified the tab
> indentation with cat -T  to ensure the tabs were being used.FS,The current version of
> the scripts in v6 should already follow the standard pgindent/pgperltidy formatting
> 
> If there is still any specific section that appears mis-indented on your
> side, please let me know and I will adjust it.

The only documentation that I have been following on this matter
exists in src/tools/pgindent/README.  That may be an issue with your
environment, I cannot say for sure.  And I am pretty sure that my
environment is handling things the way the README tells.

Anyway, after more review of the refactoring patch, I have noticed
that we were losing quite a few details about the reasons why we are
doing things the way they are.

So I have added more details about to keep things a maximum consistent
with what we had documented:
- The shared library check requirement, mentioning that the check is
skipped for static libraries in the Makefile case (for meson, we use
libpq_so, so that did not seem strongly necessary to add there,
perhaps we should).
- The explanation for __cxa_atexit, related to OpenBSD, reusing the
same wording as previously, but in the script.
- The explanation for __tsan_func_exit with ThreadSanitizer, reusing 
the same wording as previously, but in the script.

Then applied the result as 4a8e6f43a6b5.  Running the check for meson
may bring some surprises, but we'll see.  The buildfarm looks OK for
the moment.  Once we are completely in the clear, let's move on with
the second patch.
--
Michael

  29. Re: BUG #19095: Test if function exit() is used fail when linked static

    Peter Eisentraut <peter@eisentraut.org> — 2025-12-09T06:10:09Z

    On 09.12.25 05:16, Michael Paquier wrote:
> Then applied the result as 4a8e6f43a6b5.  Running the check for meson
> may bring some surprises, but we'll see.  The buildfarm looks OK for
> the moment.  Once we are completely in the clear, let's move on with
> the second patch.

meson gives this warning now:

../src/meson.build:31: WARNING: The variable(s) 'NM' in the input file 
'src/Makefile.global.in' are not present in the given configuration data.

Looks like a small addition on src/makefiles/meson.build would fix it.

  30. Re: BUG #19095: Test if function exit() is used fail when linked static

    Michael Paquier <michael@paquier.xyz> — 2025-12-09T06:26:00Z

    On Tue, Dec 09, 2025 at 07:10:09AM +0100, Peter Eisentraut wrote:
> meson gives this warning now:
> 
> ../src/meson.build:31: WARNING: The variable(s) 'NM' in the input file
> 'src/Makefile.global.in' are not present in the given configuration data.
> 
> Looks like a small addition on src/makefiles/meson.build would fix it.

Oops.  Let me see..  Indeed, the warning shows during the "Configuring 
Makefile.global using configuration" step.  This information has been
showing up in my logs while testing meson.

The attached takes care of the issue here.  Adding that to pgxs_bins
may look adapted at first glance, but I don't quite see the point in
exposing this information to PGXS, so pgxs_empty is a better fit?

What do you think?
--
Michael

  31. Re: BUG #19095: Test if function exit() is used fail when linked static

    VASUKI M <vasukim1992002@gmail.com> — 2025-12-09T10:23:23Z

    Thanks Michael and Peter for the detailed reviews and for taking the time
to refine and commit the updated version.

Thanks for pointing out that pgperltidy may behave differently across
environments.

On Tue, 9 Dec 2025 at 11:56, Michael Paquier <michael@paquier.xyz> wrote:

> The attached takes care of the issue here.  Adding that to pgxs_bins
> may look adapted at first glance, but I don't quite see the point in
> exposing this information to PGXS, so pgxs_empty is a better fit?
>
> Thanks for the clarification.Given that PGXS extensions don't appear to
require NM ,IMO adding it to pgxs_empty makes sense to me.It resolves the
Meson warning without exposing unnecessary variables to PGXS users.

Regards,
Vasuki M

  32. Re: BUG #19095: Test if function exit() is used fail when linked static

    Nazir Bilal Yavuz <byavuz81@gmail.com> — 2025-12-09T12:47:13Z

    Hi,

On Tue, 9 Dec 2025 at 13:23, VASUKI M <vasukim1992002@gmail.com> wrote:
>
> Thanks Michael and Peter for the detailed reviews and for taking the time to refine and commit the updated version.
>
> Thanks for pointing out that pgperltidy may behave differently across environments.
>
> On Tue, 9 Dec 2025 at 11:56, Michael Paquier <michael@paquier.xyz> wrote:
>>
>> The attached takes care of the issue here.  Adding that to pgxs_bins
>> may look adapted at first glance, but I don't quite see the point in
>> exposing this information to PGXS, so pgxs_empty is a better fit?
>>
> Thanks for the clarification.Given that PGXS extensions don't appear to require NM ,IMO adding it to pgxs_empty makes sense to me.It resolves the Meson warning without exposing unnecessary variables to PGXS users.

I agree with both of you. We do the same thing for 'ZIC' binary, so I
think putting it to pgxs_empty is the correct fix.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

  33. Re: BUG #19095: Test if function exit() is used fail when linked static

    Michael Paquier <michael@paquier.xyz> — 2025-12-09T23:11:37Z

    On Tue, Dec 09, 2025 at 03:47:13PM +0300, Bilal Yavuz wrote:
> I agree with both of you. We do the same thing for 'ZIC' binary, so I
> think putting it to pgxs_empty is the correct fix.

Thanks for double-checking.  I was not 100% sure if my analysis was
completely right as I was looking at this file for the first time.
--
Michael

  34. Re: BUG #19095: Test if function exit() is used fail when linked static

    Michael Paquier <michael@paquier.xyz> — 2025-12-10T05:14:23Z

    On Wed, Dec 10, 2025 at 08:11:37AM +0900, Michael Paquier wrote:
> On Tue, Dec 09, 2025 at 03:47:13PM +0300, Bilal Yavuz wrote:
>> I agree with both of you. We do the same thing for 'ZIC' binary, so I
>> think putting it to pgxs_empty is the correct fix.
> 
> Thanks for double-checking.  I was not 100% sure if my analysis was
> completely right as I was looking at this file for the first time.

On top of the rest, I have double-checked the buildfarm and things
seem fine with 4a8e6f43a6b5, so the last piece about pthread_exit() is
now done with 8268e66ac64c.
--
Michael