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 | 855a1b16-0dc0-42b2-8f90-79eb49cf2893@technowledgy.de обсуждение исходный текст |
Ответ на | Re: Regression tests fail with musl libc because libpq.so can't be loaded (Christophe Pettus <xof@thebuild.com>) |
Ответы |
Re: Regression tests fail with musl libc because libpq.so can't be loaded
|
Список | pgsql-bugs |
Christophe Pettus: > Given the musl (still?) does not define a preprocessor macro specific to it, is there a way of improving the test in pg_status.cto catch this case? It seems wrong that the current test passes a case that doesn't actually work. The missing macro is on purpose and unlikely to change: https://openwall.com/lists/musl/2013/03/29/13 I also found this thread, which discusses exactly our case: https://www.openwall.com/lists/musl/2022/08/17/1 Some quotes from that thread: > I understand that what Postgres et al are doing is a nasty hack. And: > Applications that *really* want setproctitle type functionality can > presumably do something like re-exec themselves with a suitably large > argv[0] to give them safe space to overwrite with their preferred > message, rather than UB trying to relocate the environment (and auxv? > how? they can't tell libc they moved it) to some other location. Could that be a more portable way of doing this? Best, Wolfgang
В списке pgsql-bugs по дате отправления: