Re: Regression tests fail with musl libc because libpq.so can't be loaded
От | Thomas Munro |
---|---|
Тема | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Дата | |
Msg-id | CA+hUKGJhp0opkCybdOrbQSMyHX8cRuLh2ygkqtivizCqK6kfOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Regression tests fail with musl libc because libpq.so can't be loaded (Wolfgang Walther <walther@technowledgy.de>) |
Ответы |
Re: Regression tests fail with musl libc because libpq.so can't be loaded
Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Список | pgsql-bugs |
On Sun, Mar 17, 2024 at 4:56 AM Wolfgang Walther <walther@technowledgy.de> wrote: > Any ideas? I'd look into whether there is a difference in the rules it uses for deciding not to trust LD_LIBRARY_PATH, which seems to be around here somewhere: https://github.com/bminor/musl/blob/7ada6dde6f9dc6a2836c3d92c2f762d35fd229e0/ldso/dynlink.c#L1812 I wonder if you can break into an affected program and check out the magic there. FWIW on MacOS something equivalent happens at the moment we execute a shell, because the system shell is 'code signed' and that OS treats signed stuff similar to setuid binaries for this purpose (IIRC setting SHELL to point to a suitable unsigned shell could work around the problem there?) Another interesting thing that came up when I googled musl/glibc differences -- old but looks plausibly still true (not that I expect our code to be modifying that stuff in place, just something to check): https://www.openwall.com/lists/musl/2014/08/31/14
В списке pgsql-bugs по дате отправления: