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: Bruce Momjian <bruce@momjian.us>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, Christophe Pettus <xof@thebuild.com>, Andrew Dunstan <andrew@dunslane.net>, Wolfgang Walther <walther@technowledgy.de>, PostgreSQL Bugs <pgsql-bugs@lists.postgresql.org>

Date: 2024-03-20T02:12: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 →

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 Wed, Mar 20, 2024 at 2:27 PM Bruce Momjian <bruce@momjian.us> wrote:
> I am just cautious about changing behavior on our most common platform
> for a libc library I have never heard of.

Yeah, I hear you.  I don't have a dog in this race, I just like
retro-computing mysteries and arguments about the meaning of
standards...  That said I'm pretty sure no one should be running
production PostgreSQL systems held together by LD_LIBRARY_PATH, and if
they do, it looks like systemd/rc.d scripts set a bunch of PG_OOM_BLAH
stuff just before the start the cluster that would provide extra chaff
in front of LD_XXX stuff defined earlier, and then pg_ctl inserts even
more, and even if they don't use any of that stuff and just run the
postmaster directly with some other homegrown tooling, now we're down
to very niche/expert scenarios where it should be acceptable to point
to this thread that says "try setting an extra dummy variable after
you set LD_XXX!".