Thread

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