Re: Regression tests fail with musl libc because libpq.so can't be loaded

On Sat, Mar 16, 2024 at 11:55 AM Wolfgang Walther <walther(at)technowledgy(dot)de>
wrote:

> Tom Lane:
> > Why do you think this is our bug and not musl's?
>
> Because I tried to reproduce with musl directly with a very simple
> example as mentioned in:
>
> > To rule out a musl bug, I also put together a very simple test-case of
> an executable loading liba with dlopen(), which depends on libb and then
> constructing the same scenario with LD_LIBRARY_PATH. This works fine when
> compiled with glibc and musl, too. Thus, I believe the problem to be
> somewhere in how postgres loads those libraries.
>
> My test case looked like the attached. To compile it with musl via
> Dockerfile:
>
> docker build . -t musl-dlopen && docker run --rm musl-dlopen
>
> a.c/a.h is equivalent to libpqwalreceiver and b.c/b.h to libpq.
>
> This works fine with both musl and glibc.
>
> (Note: I also tried putting liba.so and libb.so in different folders,
> adding both to LD_LIBRARY_PATH - but that worked fine as well.)
>
> Now my very simple example probably does something different than
> postgres, so that the problem doesn't appear there. But since it seems
> possible to do this with musl in principle, it should be possible to do
> it differently in postgres to make it work, too.
>
> Any ideas?
>
>
>

On Alpine Linux, which uses musl libc, you have to run `make install`
before you can run `make check`. Have you tried
that?

(Note to self: need a new Alpine buildfarm member)

cheers

andrew