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

On Mon, Mar 18, 2024 at 10:06 AM Christophe Pettus <xof@thebuild.com> wrote:
> > On Mar 17, 2024, at 13:33, Andrew Dunstan <andrew@dunslane.net> wrote:
> > That seems a little shortsighted. If other libc implementations find it appropriate to have similar macros why should they be different?
>
> It's a philosophical argument against checking for particular libc implementations instead of particular features.  I'm not unsympathetic to that argument, but AFAICT there's no clean way of checking for this by examining feature #defines.

I like their philosophy, and I like their FAQ.  Down with software
monocultures, up with standards and cooperation.  But anyway...

I wondered for a moment if there could be a runtime way to test if
we'd broken stuff, but it seems hard without a way to ask the runtime
linker for its search path to see if it has any pointers into the
environment.  We can't, that "env_path" variable in dynlink.c is not
accessible to us by any reasonable means.  And yeah, this whole thing
is a nasty invasive hack that harks back to the 80s I assume, before
many systems provided a clean way to do this (and some never did)...

Hmm, I can think of one dirty hack on top of our existing dirty hack
that might work.  I feel bad typing this out, but here goes nothing:
In save_ps_display_args(), we compute end_of_area, stepping past
contiguous arguments and environment variables.  But what if we
terminated that if we saw an environment entry beginning "LD_"?  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