Re: Regression tests fail with musl libc because libpq.so can't be loaded - Mailing list pgsql-bugs

From Wolfgang Walther
Subject Re: Regression tests fail with musl libc because libpq.so can't be loaded
Date
Msg-id 855a1b16-0dc0-42b2-8f90-79eb49cf2893@technowledgy.de
Whole thread Raw
In response to Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Christophe Pettus <xof@thebuild.com>)
Responses Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Christophe Pettus <xof@thebuild.com>)
List 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 by date:

Previous
From: Christophe Pettus
Date:
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded
Next
From: Christophe Pettus
Date:
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded