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(),
whichdepends on libb and then constructing the same scenario with LD_LIBRARY_PATH. This works fine when compiled with
glibcand 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?
Best,
Wolfgang