Re: Regression tests fail with musl libc because libpq.so can't be loaded - Mailing list pgsql-bugs

From Wolfgang Walther
Subject Re: Regression tests fail with musl libc because libpq.so can't be loaded
Date
Msg-id c6ee6170-6aa1-436d-bc87-677ffb1c66d5@technowledgy.de
Whole thread Raw
In response to Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-bugs
Bruce Momjian:
> On Wed, Mar 20, 2024 at 10:39:20AM +0100, Wolfgang Walther wrote:
>> Peter Eisentraut:
>>> We could turn it around and do
>>>
>>> #if defined(__linux__)
>>> #if defined(__GLIBC__) || defined(__UCLIBC__ )
>>> #define PS_USE_CLOBBER_ARGV
>>> #else
>>> #define PS_USE_NONE
>>> #endif
>>> #endif
>>
>> This works as well.
> 
> Yes, I prefer this.  I am worried the environ hackery will bite us
> someday and the cause will be hard to find.

Well, the environ hackery already bit and it sure was hard to find. But 
this approach would still clobber environ happily... which is undefined 
behavior. But certainly the opt-in to known-to-be-good libc variants is 
a better approach than before.

Between this and "stop clobbering at LD_LIBRARY_PATH", I prefer the 
latter, though.

>> I also put together a PoC of what was mentioned in musl's mailing list:
>> Instead of clobbering environ at all, exec yourself again with padded argv0.
>> This works, too. Attached.
> 
> It is hard to imagine why we would add an extra exec on every Linux
> server start for this.

Would this be a problem? For a running server this would happen only 
once when the postmaster starts up, AFAICT.

Best,

Wolfgang



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded
Next
From: Wolfgang Walther
Date:
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded