Re: Regression tests fail with musl libc because libpq.so can't be loaded
От | Wolfgang Walther |
---|---|
Тема | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Дата | |
Msg-id | c6ee6170-6aa1-436d-bc87-677ffb1c66d5@technowledgy.de обсуждение исходный текст |
Ответ на | Re: Regression tests fail with musl libc because libpq.so can't be loaded (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Regression tests fail with musl libc because libpq.so can't be loaded
|
Список | 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 по дате отправления: