Re: Regression tests fail with musl libc because libpq.so can't be loaded
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Wolfgang Walther <walther@technowledgy.de>
Cc: Thomas Munro <thomas.munro@gmail.com>, peter@eisentraut.org, Christophe Pettus <xof@thebuild.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL Bugs <pgsql-bugs@lists.postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-03-20T19:42:16Z
Lists: pgsql-bugs, pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow "make check"-style testing to work with musl C library.
- d82605bcd666 14.12 landed
- 8a92b70c11ba 17.0 landed
- 7651fd387697 16.3 landed
- 7124e7d528a8 12.19 landed
- 3c3f4fd741d0 15.7 landed
- 243e9953281f 13.15 landed
-
Fix compiler warnings on MSYS2
- 8c6d30f21139 13.0 cited
On Wed, Mar 20, 2024 at 08:29:21PM +0100, Wolfgang Walther wrote: > Bruce Momjian: > > > The library/postgres docker image has been pulled about 8 billion times > > > since 2014 [1]. While we can't really tell how many of those pulled the > > > alpine variant of the image, comparing the alpine [2] and ubuntu/debian > > > [3,4] base images gives a rough estimate of >50% using alpine in general. > > > > Uh, what is the current behavior of Postgres on musl? It just fails if > > the process title is longer than argv[0] plus the environment space to > > the LD_ environment variable, and then linking fails for certain > > extensions? If there are many downloads, why would we only be getting > > this report now? > > The process title works fine. It's just the way how space is cleared for the > process title, that is causing problems elsewhere. > > The thing that is broken when running postgres on alpine/musl is, to put > libpq in a custom path and use LD_LIBRARY_PATH to find it when loading > libpqwalreceiver (+ some contrib modules). Nobody does that, especially not > in a container environment where postgres is likely the only thing running > in that container, so there is no point in using any custom library paths or > anything - the image is built once and made to work, and everybody else is > just using that working image. > > The much more practical problem is that the test suite doesn't run, because > it makes use of LD_LIBRARY_PATH for that purpose. In the past, the packagers > for alpine only disabled the failing tests, but IIRC they have given up on > that and just disabled the whole test suite by now. Thanks, that is very clear. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.