discussion: runtime `qa-vdb`

[AdelKS]

Hey,

I was wondering if the package mailspring-bin that I just updated in guru was actually up-to-date in terms of dependencies

RDEPEND="
	app-accessibility/at-spi2-core:2
	app-crypt/mit-krb5
	dev-libs/expat
	dev-libs/glib:2
	dev-libs/nspr
	dev-libs/nss
	gnome-base/gvfs
	media-libs/alsa-lib
	media-libs/mesa
	net-print/cups
	sys-apps/dbus
	dev-build/libtool
	sys-libs/db:5.3
	x11-libs/cairo
	x11-libs/gtk+:3
	x11-libs/libdrm
	x11-libs/libX11
	x11-libs/libxcb
	x11-libs/libXcomposite
	x11-libs/libXdamage
	x11-libs/libXext
	x11-libs/libXfixes
	x11-libs/libxkbcommon
	x11-libs/libXrandr
	x11-libs/pango
	x11-misc/xdg-utils
"

For which qa-vdb says this

qa-vdb mailspring-bin                                                                                                                                     !10092
VDB: detected possibly incorrect RDEPEND (mail-client/mailspring-bin-1.15.1)
 > sys-apps/systemd

Then I thought of running

pgrep mailspring | xargs -L1 lsof -p | grep -E -o "/usr/.*\.so(\.[0-9]+)*" | sort | uniq 
/usr/lib64/gbm/dri_gbm.so
/usr/lib64/gio/modules/libdconfsettings.so
/usr/lib64/gio/modules/libgvfsdbus.so
/usr/lib64/gtk-3.0/modules/libcolorreload-gtk-module.so
/usr/lib64/gtk-3.0/modules/libwindow-decorations-gtk-module.so
/usr/lib64/gvfs/libgvfscommon.so
/usr/lib64/ld-linux-x86-64.so.2
/usr/lib64/libasound.so.2.0.0
/usr/lib64/libatk-1.0.so.0.25410.1
/usr/lib64/libatk-bridge-2.0.so.0.0.0
/usr/lib64/libatspi.so.0.0.1
/usr/lib64/libblkid.so.1.1.0
/usr/lib64/libbz2.so.1.0.8
/usr/lib64/libcairo-gobject.so.2.11804.4
/usr/lib64/libcairo.so.2.11804.4
/usr/lib64/libcap.so.2.71
/usr/lib64/libcrypto.so.3
/usr/lib64/libc.so.6
/usr/lib64/libcups.so.2
/usr/lib64/libdbus-1.so.3.38.3
/usr/lib64/libdl.so.2
/usr/lib64/libdrm_amdgpu.so.1.124.0
/usr/lib64/libdrm.so.2.124.0
/usr/lib64/libEGL_mesa.so.0.0.0
/usr/lib64/libEGL.so.1.1.0
/usr/lib64/libelf-0.193.so
/usr/lib64/libepoxy.so.0.0.0
/usr/lib64/libexpat.so.1.10.2
/usr/lib64/libffi.so.8.1.4
/usr/lib64/libfontconfig.so.1.15.0
/usr/lib64/libfreetype.so.6.20.2
/usr/lib64/libfribidi.so.0.4.0
/usr/lib64/libgallium-25.0.4.so
/usr/lib64/libgbm.so.1.0.0
/usr/lib64/libgdk-3.so.0.2417.32
/usr/lib64/libgdk_pixbuf-2.0.so.0.4200.12
/usr/lib64/libgio-2.0.so.0.8400.1
/usr/lib64/libGLdispatch.so.0.0.0
/usr/lib64/libglib-2.0.so.0.8400.1
/usr/lib64/libgmodule-2.0.so.0.8400.1
/usr/lib64/libgmp.so.10.5.0
/usr/lib64/libgnutls.so.30.40.3
/usr/lib64/libgobject-2.0.so.0.8400.1
/usr/lib64/libgraphite2.so.3.2.1
/usr/lib64/libgtk-3.so.0.2417.32
/usr/lib64/libharfbuzz.so.0.61110.0
/usr/lib64/libhogweed.so.6.10
/usr/lib64/libicudata.so.76.1
/usr/lib64/libicuuc.so.76.1
/usr/lib64/libidn2.so.0.4.0
/usr/lib64/libjpeg.so.62.4.0
/usr/lib64/libmount.so.1.1.0
/usr/lib64/libm.so.6
/usr/lib64/libnettle.so.8.10
/usr/lib64/libnspr4.so
/usr/lib64/libnss3.so
/usr/lib64/libnss_mymachines.so.2
/usr/lib64/libnss_resolve.so.2
/usr/lib64/libnssutil3.so
/usr/lib64/libp11-kit.so.0.4.1
/usr/lib64/libpango-1.0.so.0.5400.0
/usr/lib64/libpangocairo-1.0.so.0.5400.0
/usr/lib64/libpangoft2-1.0.so.0.5400.0
/usr/lib64/libpcre2-8.so.0.14.0
/usr/lib64/libpixman-1.so.0.44.2
/usr/lib64/libplc4.so
/usr/lib64/libplds4.so
/usr/lib64/libpng16.so.16.47.0
/usr/lib64/libpthread.so.0
/usr/lib64/libsmime3.so
/usr/lib64/libSPIRV-Tools.so
/usr/lib64/libssl.so.3
/usr/lib64/libsystemd.so.0.40.0
/usr/lib64/libtasn1.so.6.6.4
/usr/lib64/libudev.so.1.7.10
/usr/lib64/libunistring.so.5.2.0
/usr/lib64/libva-drm.so.2.2200.0
/usr/lib64/libva.so.2.2200.0
/usr/lib64/libwayland-client.so.0.23.1
/usr/lib64/libwayland-cursor.so.0.23.1
/usr/lib64/libwayland-egl.so.1.23.1
/usr/lib64/libwayland-server.so.0.23.1
/usr/lib64/libX11.so.6.4.0
/usr/lib64/libX11-xcb.so.1.0.0
/usr/lib64/libXau.so.6.0.0
/usr/lib64/libxcb-dri2.so.0.0.0
/usr/lib64/libxcb-dri3.so.0.1.0
/usr/lib64/libxcb-present.so.0.0.0
/usr/lib64/libxcb-randr.so.0.1.0
/usr/lib64/libxcb-render.so.0.0.0
/usr/lib64/libxcb-shm.so.0.0.0
/usr/lib64/libxcb.so.1.1.0
/usr/lib64/libxcb-sync.so.1.0.0
/usr/lib64/libxcb-xfixes.so.0.0.0
/usr/lib64/libXcomposite.so.1.0.0
/usr/lib64/libXcursor.so.1.0.2
/usr/lib64/libXdamage.so.1.1.0
/usr/lib64/libXdmcp.so.6.0.0
/usr/lib64/libXext.so.6.4.0
/usr/lib64/libXfixes.so.3.1.0
/usr/lib64/libXi.so.6.1.0
/usr/lib64/libxkbcommon.so.0.9.0
/usr/lib64/libxml2.so.2.13.7
/usr/lib64/libXrandr.so.2.2.0
/usr/lib64/libXrender.so.1.3.0
/usr/lib64/libxshmfence.so.1.0.0
/usr/lib64/libz.so.1.3.1
/usr/lib64/libzstd.so.1.5.7
/usr/lib/gcc/x86_64-pc-linux-gnu/15/libgcc_s.so.1
/usr/lib/gcc/x86_64-pc-linux-gnu/15/libstdc++.so.6.0.34
/usr/lib/llvm/19/lib64/libLLVM.so.19.1
/usr/share/mailspring/libEGL.so
/usr/share/mailspring/libffmpeg.so
/usr/share/mailspring/libGLESv2.so

Which can be piped to equery belongs

media-libs/mesa-25.0.4-r1 (/usr/lib64/gbm/dri_gbm.so)
gnome-base/dconf-0.40.0 (/usr/lib64/gio/modules/libdconfsettings.so)
gnome-base/gvfs-1.56.1-r1 (/usr/lib64/gio/modules/libgvfsdbus.so)
kde-plasma/kde-gtk-config-6.3.4 (/usr/lib64/gtk-3.0/modules/libcolorreload-gtk-module.so)
kde-plasma/kde-gtk-config-6.3.4 (/usr/lib64/gtk-3.0/modules/libwindow-decorations-gtk-module.so)
gnome-base/gvfs-1.56.1-r1 (/usr/lib64/gvfs/libgvfscommon.so)
media-libs/alsa-lib-1.2.14 (/usr/lib64/libasound.so.2.0.0)
app-accessibility/at-spi2-core-2.54.1 (/usr/lib64/libatk-1.0.so.0.25410.1)
app-accessibility/at-spi2-core-2.54.1 (/usr/lib64/libatk-bridge-2.0.so.0.0.0)
app-accessibility/at-spi2-core-2.54.1 (/usr/lib64/libatspi.so.0.0.1)
sys-apps/util-linux-2.41 (/usr/lib64/libblkid.so.1.1.0)
app-arch/bzip2-1.0.8-r5 (/usr/lib64/libbz2.so.1.0.8)
x11-libs/cairo-1.18.4-r1 (/usr/lib64/libcairo-gobject.so.2.11804.4)
x11-libs/cairo-1.18.4-r1 (/usr/lib64/libcairo.so.2.11804.4)
sys-libs/libcap-2.71 (/usr/lib64/libcap.so.2.71)
dev-libs/openssl-3.5.0 (/usr/lib64/libcrypto.so.3)
net-print/cups-2.4.12 (/usr/lib64/libcups.so.2)
sys-apps/dbus-1.16.2 (/usr/lib64/libdbus-1.so.3.38.3)
x11-libs/libdrm-2.4.124 (/usr/lib64/libdrm_amdgpu.so.1.124.0)
x11-libs/libdrm-2.4.124 (/usr/lib64/libdrm.so.2.124.0)
media-libs/mesa-25.0.4-r1 (/usr/lib64/libEGL_mesa.so.0.0.0)
media-libs/libglvnd-1.7.0 (/usr/lib64/libEGL.so.1.1.0)
dev-libs/elfutils-0.193 (/usr/lib64/libelf-0.193.so)
media-libs/libepoxy-1.5.10-r3 (/usr/lib64/libepoxy.so.0.0.0)
dev-libs/expat-2.7.1 (/usr/lib64/libexpat.so.1.10.2)
dev-libs/libffi-3.4.8-r1 (/usr/lib64/libffi.so.8.1.4)
media-libs/fontconfig-2.16.2 (/usr/lib64/libfontconfig.so.1.15.0)
media-libs/freetype-2.13.3 (/usr/lib64/libfreetype.so.6.20.2)
dev-libs/fribidi-1.0.16 (/usr/lib64/libfribidi.so.0.4.0)
media-libs/mesa-25.0.4-r1 (/usr/lib64/libgallium-25.0.4.so)
media-libs/mesa-25.0.4-r1 (/usr/lib64/libgbm.so.1.0.0)
x11-libs/gtk+-3.24.49 (/usr/lib64/libgdk-3.so.0.2417.32)
x11-libs/gdk-pixbuf-2.42.12 (/usr/lib64/libgdk_pixbuf-2.0.so.0.4200.12)
dev-libs/glib-2.84.1 (/usr/lib64/libgio-2.0.so.0.8400.1)
media-libs/libglvnd-1.7.0 (/usr/lib64/libGLdispatch.so.0.0.0)
dev-libs/glib-2.84.1 (/usr/lib64/libglib-2.0.so.0.8400.1)
dev-libs/glib-2.84.1 (/usr/lib64/libgmodule-2.0.so.0.8400.1)
dev-libs/gmp-6.3.0-r1 (/usr/lib64/libgmp.so.10.5.0)
net-libs/gnutls-3.8.9-r1 (/usr/lib64/libgnutls.so.30.40.3)
dev-libs/glib-2.84.1 (/usr/lib64/libgobject-2.0.so.0.8400.1)
media-gfx/graphite2-1.3.14_p20210810-r3 (/usr/lib64/libgraphite2.so.3.2.1)
x11-libs/gtk+-3.24.49 (/usr/lib64/libgtk-3.so.0.2417.32)
media-libs/harfbuzz-11.1.0 (/usr/lib64/libharfbuzz.so.0.61110.0)
dev-libs/nettle-3.10.1 (/usr/lib64/libhogweed.so.6.10)
dev-libs/icu-76.1-r1 (/usr/lib64/libicudata.so.76.1)
dev-libs/icu-76.1-r1 (/usr/lib64/libicuuc.so.76.1)
net-dns/libidn2-2.3.8 (/usr/lib64/libidn2.so.0.4.0)
media-libs/libjpeg-turbo-3.1.0 (/usr/lib64/libjpeg.so.62.4.0)
sys-apps/util-linux-2.41 (/usr/lib64/libmount.so.1.1.0)
dev-libs/nettle-3.10.1 (/usr/lib64/libnettle.so.8.10)
dev-libs/nspr-4.36 (/usr/lib64/libnspr4.so)
dev-libs/nss-3.110 (/usr/lib64/libnss3.so)
sys-apps/systemd-257.5 (/usr/lib64/libnss_mymachines.so.2)
sys-apps/systemd-257.5 (/usr/lib64/libnss_resolve.so.2)
dev-libs/nss-3.110 (/usr/lib64/libnssutil3.so)
app-crypt/p11-kit-0.25.5 (/usr/lib64/libp11-kit.so.0.4.1)
x11-libs/pango-1.54.0 (/usr/lib64/libpango-1.0.so.0.5400.0)
x11-libs/pango-1.54.0 (/usr/lib64/libpangocairo-1.0.so.0.5400.0)
x11-libs/pango-1.54.0 (/usr/lib64/libpangoft2-1.0.so.0.5400.0)
dev-libs/libpcre2-10.45 (/usr/lib64/libpcre2-8.so.0.14.0)
x11-libs/pixman-0.44.2 (/usr/lib64/libpixman-1.so.0.44.2)
dev-libs/nspr-4.36 (/usr/lib64/libplc4.so)
dev-libs/nspr-4.36 (/usr/lib64/libplds4.so)
media-libs/libpng-1.6.47 (/usr/lib64/libpng16.so.16.47.0)
dev-libs/nss-3.110 (/usr/lib64/libsmime3.so)
dev-util/spirv-tools-1.4.309.0 (/usr/lib64/libSPIRV-Tools.so)
dev-libs/openssl-3.5.0 (/usr/lib64/libssl.so.3)
sys-apps/systemd-257.5 (/usr/lib64/libsystemd.so.0.40.0)
dev-libs/libtasn1-4.20.0 (/usr/lib64/libtasn1.so.6.6.4)
sys-apps/systemd-257.5 (/usr/lib64/libudev.so.1.7.10)
dev-libs/libunistring-1.3 (/usr/lib64/libunistring.so.5.2.0)
media-libs/libva-2.22.0-r1 (/usr/lib64/libva-drm.so.2.2200.0)
media-libs/libva-2.22.0-r1 (/usr/lib64/libva.so.2.2200.0)
dev-libs/wayland-1.23.1 (/usr/lib64/libwayland-client.so.0.23.1)
dev-libs/wayland-1.23.1 (/usr/lib64/libwayland-cursor.so.0.23.1)
dev-libs/wayland-1.23.1 (/usr/lib64/libwayland-egl.so.1.23.1)
dev-libs/wayland-1.23.1 (/usr/lib64/libwayland-server.so.0.23.1)
x11-libs/libX11-1.8.12 (/usr/lib64/libX11.so.6.4.0)
x11-libs/libX11-1.8.12 (/usr/lib64/libX11-xcb.so.1.0.0)
x11-libs/libXau-1.0.12 (/usr/lib64/libXau.so.6.0.0)
x11-libs/libxcb-1.17.0 (/usr/lib64/libxcb-dri2.so.0.0.0)
x11-libs/libxcb-1.17.0 (/usr/lib64/libxcb-dri3.so.0.1.0)
x11-libs/libxcb-1.17.0 (/usr/lib64/libxcb-present.so.0.0.0)
x11-libs/libxcb-1.17.0 (/usr/lib64/libxcb-randr.so.0.1.0)
x11-libs/libxcb-1.17.0 (/usr/lib64/libxcb-render.so.0.0.0)
x11-libs/libxcb-1.17.0 (/usr/lib64/libxcb-shm.so.0.0.0)
x11-libs/libxcb-1.17.0 (/usr/lib64/libxcb.so.1.1.0)
x11-libs/libxcb-1.17.0 (/usr/lib64/libxcb-sync.so.1.0.0)
x11-libs/libxcb-1.17.0 (/usr/lib64/libxcb-xfixes.so.0.0.0)
x11-libs/libXcomposite-0.4.6 (/usr/lib64/libXcomposite.so.1.0.0)
x11-libs/libXcursor-1.2.3 (/usr/lib64/libXcursor.so.1.0.2)
x11-libs/libXdamage-1.1.6 (/usr/lib64/libXdamage.so.1.1.0)
x11-libs/libXdmcp-1.1.5 (/usr/lib64/libXdmcp.so.6.0.0)
x11-libs/libXext-1.3.6 (/usr/lib64/libXext.so.6.4.0)
x11-libs/libXfixes-6.0.1 (/usr/lib64/libXfixes.so.3.1.0)
x11-libs/libXi-1.8.2 (/usr/lib64/libXi.so.6.1.0)
x11-libs/libxkbcommon-1.9.0 (/usr/lib64/libxkbcommon.so.0.9.0)
dev-libs/libxml2-2.13.7 (/usr/lib64/libxml2.so.2.13.7)
x11-libs/libXrandr-1.5.4 (/usr/lib64/libXrandr.so.2.2.0)
x11-libs/libXrender-0.9.12 (/usr/lib64/libXrender.so.1.3.0)
x11-libs/libxshmfence-1.3.3 (/usr/lib64/libxshmfence.so.1.0.0)
sys-libs/zlib-1.3.1-r1 (/usr/lib64/libz.so.1.3.1)
app-arch/zstd-1.5.7-r1 (/usr/lib64/libzstd.so.1.5.7)
sys-devel/gcc-15.1.0 (/usr/lib/gcc/x86_64-pc-linux-gnu/15/libgcc_s.so.1)
sys-devel/gcc-15.1.0 (/usr/lib/gcc/x86_64-pc-linux-gnu/15/libstdc++.so.6.0.34)
llvm-core/llvm-19.1.7 (/usr/lib/llvm/19/lib64/libLLVM.so.19.1)
mail-client/mailspring-bin-1.15.1 (/usr/share/mailspring/libEGL.so)
mail-client/mailspring-bin-1.15.1 (/usr/share/mailspring/libffmpeg.so)
mail-client/mailspring-bin-1.15.1 (/usr/share/mailspring/libGLESv2.so)

I however think that lsof does also show the "transitive" dependencies of the app (the dependencies of the shared libs opened by the app). But that can be worked out by removing the dependencies of the dependencies by using scanelf -n on every line above that does not belong to the package in question. Effectively giving a "runtime" version of qa-vdb, do you think it would be a good addition ? In general, some of the results can be optfeatures but would already be a pretty good addition !

[thesamesam]

That would involve running it and dlopen may happen at any time during process execution. I don't see how lsof does anything useful here. Best we could do is start to look at the new systemd-driven ELF tag for this.

[AdelKS]

That would involve running it and dlopen may happen at any time during process execution

Yeah exactly, check for potentially missed deps while running the app. I assume you are saying that we may miss dlclosed libs or not yet dlopened libs ? yeah.

Best we could do is start to look at the new systemd-driven ELF tag for this.

Never heard of it, sounds intresting already. Do you have a link on the matter ?

[eli-schwartz]

I however think that lsof does also show the "transitive" dependencies of the app (the dependencies of the shared libs opened by the app). But that can be worked out by removing the dependencies of the dependencies by using scanelf -n on every line above that does not belong to the package in question. Effectively giving a "runtime" version of qa-vdb,

So, we use lsof to detect:

• indirect dependencies, wrongly
• dlopen dependencies

then we filter back out all the indirect dependencies (ok...), as well as all the dlopen dependencies that are ALSO indirect dependencies (wrong??), and we end up with an incorrect list of things that may be candidates for optfeatures?

Do I understand the feature request correctly?

[AdelKS]

then we filter back out all the indirect dependencies (ok...), as well as all the dlopen dependencies that are ALSO indirect dependencies (wrong??), and we end up with an incorrect list of things that may be candidates for optfeatures?

Do I understand the feature request correctly?

That's basically it yes. But we'd end up with an "at least that" list, in the sense that it can be bigger than what qa-vdb gives, and if it is the case, then it's either an optfeature or an rdepend. For example: in the app above you can see that lsof captured wayland which probably got dlopened by Electron after I added --ozone-platform-hint=auto --enable-wayland-ime in the Exec line of its .desktop file.

[eli-schwartz]

That would involve running it and dlopen may happen at any time during process execution

Yeah exactly, check for potentially missed deps while running the app. I assume you are saying that we may miss dlclosed libs ? or that lsof doesn't show dlopened libs ?

Best we could do is start to look at the new systemd-driven ELF tag for this.

Never heard of it, sounds intresting already. Do you have a link on the matter ?

https://github.com/systemd/systemd/blob/main/docs%2FELF_DLOPEN_METADATA.md

[eli-schwartz]

But we'd end up with "at least that" list, in the sense that it can be bigger than what qa-vdb gives, and if it is the case, then it's either an optfeature or an rdepend. For example: in the app above you can see that lsof captured wayland which probably got dlopened by Electron after I added --ozone-platform-hint=auto --enable-wayland-ime in the Exec line of its .desktop file.

How do you distinguish Wayland, that was dlopened, versus Wayland's dependencies, that aren't? How do you tell whether one of Wayland's dependencies was also directly dlopened?

Regardless, an ebuild (or ebuild hook) can't run the built program from $D, can't run the program reliably at all if cross builds are considered, can't guarantee an X or Wayland server is running, can't know what flags are needed to successfully run a program in ${ED}/usr/bin but can't assume programs have desktop files to use instead, can't know what filesystem modifications would be made in /root when a program is automatically launched, can't reliably signal the program to shutdown, can't tell whether running the program without arguments will open a remotely accessible server without a configured password to protect against people port scanning and logging into your lsof checks...

If it was desirable to use lsof for this I'd recommend an optional mode that takes an lsof dump as an argument and analyzes it.

[AdelKS]

This issue is not about about finding the magical foolproof silver bullet of figuring out a package's dependencies, but about adding one more tool to the portfolio. In this case to help with tracking down potential dependencies to packages for which it's unclear / too complex (e.g. binary packages).

Okay, if I step back a little, qa-vdb's shortcoming is not detecting dlopen dependencies. And my suggestion through this issue is on whether it's worth it to use lsof on running programs for that, the main shortcoming to that is that it shows indirect dependencies (I actually did not dig deeper into lsof to know what exacty it shows and can show).

Now, back down the lsof path rabbit hole.

How do you distinguish Wayland, that was dlopened, versus Wayland's dependencies, that aren't? How do you tell whether one of Wayland's dependencies was also directly dlopened?

I was assuming that shared libraries don't dlopen their dependencies, but they actually can ? Alright, one idea maybe: use the ebuild of the package owning the lsof listed library instead of scanelf -n ? Feels too far fetched to me.

Is there actually a better tool than lsof to get the libraries loaded directly by a process, and not the ones loaded indirectly ? That can only happen if Linux differentiates between those two, in some way 🤔

If it was desirable to use lsof for this I'd recommend an optional mode that takes an lsof dump as an argument and analyzes it.

That would be the only way, or a list of PIDs/process names. It cannot be fully automated.

[eli-schwartz]

Now, back down the lsof path rabbit hole.

How do you distinguish Wayland, that was dlopened, versus Wayland's dependencies, that aren't? How do you tell whether one of Wayland's dependencies was also directly dlopened?

I was assuming that shared libraries don't dlopen their dependencies, but they actually can ? Alright, one idea maybe: use the ebuild of the package owning the lsof listed library instead of scanelf -n ? Feels too far fetched to me.

No, I mean you package program "foo", which dlopens "libone", and "libone" links directly to "libtwo".

But program "foo" also dlopens "libtwo".

If you discard libtwo because it's loaded as a recursive dependency of the dlopen, how do you handle the fact that it's dlopened as well, and should be an optional dep?

Is there actually a better tool than lsof to get the libraries loaded directly by a process, and not the ones loaded indirectly ? That can only happen if Linux differentiates between those two, in some way 🤔

Surely it is differentiated. You run tracing software, and have it catch all usage of the "dlopen()" C library function and log what it opens. That tells you what is getting dlopened, rather than just checking what library files are "somehow mapped into the process".

[AdelKS]

No, I mean you package program "foo", which dlopens "libone", and "libone" links directly to "libtwo". But program "foo" also dlopens "libtwo".

That actual dependency would just not be captured by this approach x)

Surely it is differentiated. You run tracing software, and have it catch all usage of the "dlopen()" C library function and log what it opens. That tells you what is getting dlopened, rather than just checking what library files are "somehow mapped into the process".

Well here you go ! That's much better than looking at the output of lsof ! Down the bin it goes. So... how about making that wrapper with tracing, how would it look ? qa-trace <exec-path> and it outputs the package names as they get dlopened, if there's any ?