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

Поиск
Список
Период
Сортировка
От VASUKI M
Тема Re: BUG #19095: Test if function exit() is used fail when linked static
Дата
Msg-id CACTYHzimf5+6gp6HzCerZpWh4o2_TW6-S3k3+2YK5mnoQa-+tg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #19095: Test if function exit() is used fail when linked static  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: BUG #19095: Test if function exit() is used fail when linked static
Список pgsql-bugs
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
Вложения

В списке pgsql-bugs по дате отправления: