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

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: torsten.rupp@gmx.net, pgsql-bugs@lists.postgresql.org
Date: 2025-10-28T03:16:49Z
Lists: pgsql-bugs, pgsql-hackers

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

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