[Solved?]How to detect libararies used by dlopen without launching ?

oech3 · 2025-04-25 10:35:55

namcap, ldd, or other tools some times miss Qt plugins required.

Is there any way to detect them without launching binary (on strace)?

This is also needed for repackaging non-free .deb, .rpm tarballs depending legacy version of libicu*.so optionally.

Last edited by oech3 (2025-04-29 07:57:20)

seth · 2025-04-25 12:46:19

strace or LD_DEBUG, but not

without launching binary

, notably since the object could be loaded by some linked library and opportunistically (load everything in path /usr/lib/qt6/plugins/foo/ or so)

The "d" in "dlopen" is for "dynamically" - at runtime.

oech3 · 2025-04-27 07:57:35

Never implemented, but

namcap-run /pathto/program

could be possible in the future?

Last edited by oech3 (2025-04-27 07:58:29)

loqs · 2025-04-27 18:27:41

Have you looked at https://github.com/systemd/systemd/comm … d277ece174?

seth · 2025-04-27 19:27:43

https://gitlab.archlinux.org/archlinux/ … issues/271
Also

some times miss Qt plugins required

grep .note.dlopen /usr/lib/libQt6*.so

And while I'm not sure what "Qt plugins required" indicates, plugins are typically not a conclusive list, and afaict there's no path nor globbing in that spec, so how can that cover eg. reliance on https://archlinux.org/packages/extra/x8 … geformats/ ?

Hard dependency on libicuwhatever.so.xy could be covered but

repackaging non-free .deb, .rpm tarballs

will probably spoil that.

namcap-run /pathto/program

LD_DEBUG=files phototonic |& awk -F '([[:space:]]|=)' '/dynamically loaded/{print $6}'

But this will eg. also list your local style plugin and the libgl implementation drawn in by libglvnd

oech3 · 2025-04-28 06:49:37

https://github.com/systemd/systemd/comm … d277ece174

Thankyou. I did'nt know .note.dlopen section. But it seems recently introduced and may not used for legacy prebuild binary...

what "Qt plugins required" indicates

Automatic optdepends detection for packages.

also list your local style plugin and the libgl implementation drawn in by libglvnd

It seems surrender is an answer for me.

seth · 2025-04-28 13:57:27

It seems surrender is an answer for me.

You'll dlopen "false positives" but could maintain some blacklist (LD_DEBUG w/o the awk actually tells you what dlopens the library to ballpark its relevance) but any such approach will remain a heuristic, yes. Also because to detect such dlopened object, you'll need it locally.
The only way to know what X might dlopen but you've never heard of is to check the documentation, the code or back with the devs.

oech3 · 2025-04-29 07:59:19

The only way to know what X might dlopen but you've never heard of is to check the documentation, the code or back with the devs.

OK (not OK).

Arch Linux

#1 2025-04-25 10:35:55

[Solved?]How to detect libararies used by dlopen without launching ?

#2 2025-04-25 12:46:19

Re: [Solved?]How to detect libararies used by dlopen without launching ?

#3 2025-04-27 07:57:35

Re: [Solved?]How to detect libararies used by dlopen without launching ?

#4 2025-04-27 18:27:41

Re: [Solved?]How to detect libararies used by dlopen without launching ?

#5 2025-04-27 19:27:43

Re: [Solved?]How to detect libararies used by dlopen without launching ?

#6 2025-04-28 06:49:37

Re: [Solved?]How to detect libararies used by dlopen without launching ?

#7 2025-04-28 13:57:27

Re: [Solved?]How to detect libararies used by dlopen without launching ?

#8 2025-04-29 07:59:19

Re: [Solved?]How to detect libararies used by dlopen without launching ?

Board footer