Dynamic library loading inner workings

Carlos O'Donell carlos@systemhalted.org
Sun Dec 5 16:34:00 GMT 2010

On Thu, Dec 2, 2010 at 5:13 PM, Andreas Fink
<andreas.fink85@googlemail.com> wrote:
> Thanks for the relocation keyword. I tried what you've suggested and I was running it with LD_DEBUG=all. I think this is the line which is interesting:
> file=/usr/lib/qt4/libQtGui.so [0];  needed by /usr/lib64/qt4/libQtCore.so.4 [0] (relocation dependency)
> Several questions come to my mind:
> - Do I understand it correctly, that libQtCore.so needs libQtGui.so, so this is the reason why unloading libQtGui will fail?


> - What is a relocation dependency (maybe you have some informative link, couldn't find anything useful with google except the dl-lookup.c)?

You need to learn about relocations in general to understand the
context, for any beginner I strongly recommend reading "Linkers &
Loaders" by Levine

A relocation dependency occurs when an address in one shared library
(libQtCore.so) is relocated to point at data or code in another shared
library (libQtGUI.so). Unloading the library that is dependend upon
would leave the dependent library with an invalid reference.

In general it is this type of complexity that created the loose
requirements around dlclose() needing to do anything concrete (that
and performance reasons).

> - Why can't there be a simple reference counting for dependent libraries (libQtGui needs libQtCore --> increase reference counter, libQtXml needs libQtCore --> increase reference counter, etc)

There is a simple reference count. That's how it's implemented.

> - Is there any way to make this work in a generic manner (in this case preloading libQtCore would solve it, but what if I have different libraries with the same behaviour)?

There is no generic way to handle this issue, and there are no
assurances that dlclose() will unload the shared library.

Why do you want more assurances?

What problem are you trying to solve?


More information about the Libc-help mailing list