Re: Regression tests fail with musl libc because libpq.so can't be loaded

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>

To: Wolfgang Walther <walther@technowledgy.de>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Bugs <pgsql-bugs@lists.postgresql.org>

Date: 2024-03-16T20:54:52Z

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 →

Allow "make check"-style testing to work with musl C library.
- d82605bcd666 14.12 landed
- 8a92b70c11ba 17.0 landed
- 7651fd387697 16.3 landed
- 7124e7d528a8 12.19 landed
- 3c3f4fd741d0 15.7 landed
- 243e9953281f 13.15 landed
Fix compiler warnings on MSYS2
- 8c6d30f21139 13.0 cited

On Sun, Mar 17, 2024 at 9:19 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> Another interesting thing that came up when I googled musl/glibc
> differences -- old but looks plausibly still true (not that I expect
> our code to be modifying that stuff in place, just something to
> check):
>
> https://www.openwall.com/lists/musl/2014/08/31/14

Hmm, that does mention setproctitle, and our ps_status.c does indeed
clobber some stuff in that region (in fact our ps_status.c is likely
derived from the setproctitle() function from sendmail AFAICT).  But
that's in our "backend" server processes, unlike the problems we have
on Macs... oh but you're failing to load libpqwalreceiver.so which
makes some sense for the backend hypothesis.  What happens if you hack
ps_status.c to use PS_USE_NONE?