Re: [musl] Shared library loading

[Markus Wichmann <nullplan@gmx.net>]

On Thu, May 21, 2020 at 02:27:24PM +0300, Alexander Scherbatiy wrote:
> Hello,
>
> I use Alpine Linux 3.11.6 with musl libc (x86_64) version 1.1.24.
>
> I have two shared libraries "a" and "b" each of which is placed in its own
> directory and lib "b" depends on "a".
> First, I use dlopen to load lib "a" with "RTLD_NOW | RTLD_GLOBAL" flags.
> Second, I load lib "b" with  flag "RTLD_LAZY".
>
> The "b" library loading works on my Ubuntu 19.10 and fails on Alpine 3.11.6
> with message:
>   dlopen failed: Error loading shared library liba.so: No such file or
> directory (needed by /root/load-lib-sample/bin/b/libb.so)
> Should it work on Alpine with musl libc as well?

[...]

I shall leave the "Should it work" to others who know more about this
than me. But I will tackle the "Why doesn't it work". It appears however
the behavior is intentional (whether the consequences are as well
remains to be seen). Namely in line 1140f. of dynlink.c (revision
72658c65):


|/* Add a shortname only if name arg was not an explicit pathname. */
|if (pathname != name) p->shortname = strrchr(p->name, '/')+1;

This means, in your case, the DSO handle for liba does not get a short
name, so when libb is loaded, it is not detected that liba has already
been loaded (only the shortname is used for that purpose). And since
your files are in different directories, liba is also not found to be
loaded again. To work around this, you can set LD_LIBRARY_PATH to the
directory containing liba. In that case, when loading libb, the
dependency will be found with the environment search, and since liba was
already loaded, the loop in lines 1085ff. will find the handle and even
assign a shortname. The shortname is only used for checking of
duplicates.

Ciao,
Markus