Re: Regression tests fail with musl libc because libpq.so can't be loaded
От | Christophe Pettus |
---|---|
Тема | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Дата | |
Msg-id | E5D4E3AE-C926-48C5-84DC-57E3E9357675@thebuild.com обсуждение исходный текст |
Ответ на | Re: Regression tests fail with musl libc because libpq.so can't be loaded (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Regression tests fail with musl libc because libpq.so can't be loaded
|
Список | pgsql-bugs |
> 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 findinglibraries... 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 ofdetecting a libc that passes the other tests but doesn't support any of the existing hacks.
В списке pgsql-bugs по дате отправления: