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)
