How can I trace what libraries an application is calling?

Context

In the aforementioned, solely mediainfo-qt-25.03-1.fc42.x86_64’s call to QtWidgets.QFileDialog somehow fails due to it trying to call samba, imobiledevice, and libusbmuxd, resulting in a segmenatation fault. A competent contributor has diagnosed the issue to be a fault in how a library is linked, which he believes is out of his control.

Question

Consequently, I’d like to trace mediainfo on my affected OS installation and an unaffected VM, in order to ascertain what differs in their call stacks. How would one go about this on Fedora?

Tangential

In that same discussion, the undermentioned was stated by the contributor:

I actually just learned how Linux links libraries thanks to this issue and am surprised by how easy it is to have conflicts like this. I don’t think it is possible for Windows to run into an issue like this as every function has a specified DLL name that it should be loaded from.

If anyone, per the aforecited context, understands this, would you elaborate on this point? I ask because I would like to understand this purported deficiency so that I might advise others on it, and because I’m always interested in how one OS does something better than another.

Check ldd for the app executable, or try launching it with strace.

4 Likes

If the program dynamically opens libraries then you will only see them with strace.

If the program stays running you can use lsof on the process and see the libs that way.

2 Likes

Also check out ltrace.

@jjames, according to stackoverflow.com/revisions/13866611/3, ltrace appears usable for this case, but perhaps solely supports a subset - DLLs - of what strace does - dynamically and statically-linked libraries. Have I understood correctly?

Yes, that is correct. Perhaps I misunderstood. I thought you were only interested in tracing calls to dynamicallly linked libraries.

1 Like

@jjames, I’d not considered that. However, that might have actually been more useful!