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
shouldthey be different? 
>
> It's a philosophical argument against checking for particular libc implementations instead of particular features.
I'mnot 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