Szabolcs:

On 06/23/2016 11:15 PM, Szabolcs Nagy wrote:

* Andrei Pozolotin <andrei.pozolotin@gmail.com> [2016-06-23 19:42:44 +0000]:

b) while at the same time musl ldd reporting that library dependency
tree is resolved with no error:

lddtree /usr/lib/libswt-atk-gtk-4530.so

that's not musl's ldd, but scanelf from pax-utils

thank you for pointing out.

when debugging such a complicated setup the output
of tools that may use subtly different library paths
and symbol resolution logic is not very helpful.

ok, got it.

ldd /usr/lib/libswt-gtk-4530.so

ldd /usr/lib/libswt-gtk-4530.so
ldd (0x55e333e6c000)
libc.musl-x86_64.so.1 => ldd (0x55e333e6c000)

ldd /usr/lib/libswt-atk-gtk-4530.so

ldd /usr/lib/libswt-atk-gtk-4530.so
        ldd (0x55edc6edc000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x7fc763298000)
        libc.musl-x86_64.so.1 => ldd (0x55edc6edc000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x7fc763058000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7fc762d6d000)
        libintl.so.8 => /usr/lib/libintl.so.8 (0x7fc762b5f000)
        libffi.so.6 => /usr/lib/libffi.so.6 (0x7fc762957000)
        libpcre.so.1 => /usr/lib/libpcre.so.1 (0x7fc7626fe000)

would be more interesting..

but even then we don't know what's going on
(if libswt-gtk-4530.so is dlopened with RTLD_LOCAL
then its libgobject dependency might not be visible
to libswt-atk-gtk-4530)