From: | Wolfgang Walther <walther(at)technowledgy(dot)de> |
---|---|
To: | Christophe Pettus <xof(at)thebuild(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Date: | 2024-03-17 13:11:19 |
Message-ID: | 855a1b16-0dc0-42b2-8f90-79eb49cf2893@technowledgy.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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.c to 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
From | Date | Subject | |
---|---|---|---|
Next Message | Christophe Pettus | 2024-03-17 15:44:45 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Previous Message | Christophe Pettus | 2024-03-17 10:33:52 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
From | Date | Subject | |
---|---|---|---|
Next Message | Kambam Vinay | 2024-03-17 14:05:57 | Re: Fix for timestamp lag issue from emit_log_hook when GUC log_line_prefix has '%m' |
Previous Message | Alvaro Herrera | 2024-03-17 13:07:42 | Re: Simplify backtrace_functions GUC code |