Horton

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

Christophe Pettus <xof@thebuild.com>

View thread
From: Christophe Pettus <xof@thebuild.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Wolfgang Walther <walther@technowledgy.de>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Bugs <pgsql-bugs@lists.postgresql.org>
Date: 2024-03-18T09:33:45Z
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. Allow "make check"-style testing to work with musl C library.

  2. Fix compiler warnings on MSYS2


> On Mar 17, 2024, at 16:20, Thomas Munro <thomas.munro@gmail.com> wrote:
> 
> We'd
> still feel free to clobber the memory up to that point (rather than
> limiting ourselves to the argv space, another more conservative choice
> that might truncate a few PS display messages, or maybe not given the
> typical postmaster arguments, maye that'd work out OK), and we'd still
> copy the environment to somewhere new, but anything like "LD_XXX" that
> the runtime linker might have stashed a pointer to would remain valid.
> /me runs away and hides

It doesn't lack for bravery!  (And I have to just comment that the linker storing pointers into that space as a way of finding libraries... well, that doesn't get them the moral high ground for nasty hacks.)

I'm comfortable with "if you are using musl, you don't get the ps messages" as a first solution, if we can find a way of detecting a libc that passes the other tests but doesn't support any of the existing hacks.