So what is the difference between linking a .so into a library and into a executable? 发自我的 iPhone 在 2013-12-5，19:55，Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> 写道： > Hatt Tom writes: > >> 2013/12/3 Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx>: >> > Hatt Tom writes: >> > >> >> Here is one example : >> >> >> >> First, I linked liba.so into executable target by the compiler >> >> command "g++ -la " at linking stage . >> >> >> >> then ,I use dlopen to load liba.so in the executable's process . >> >> >> >> At this time ,the reference count of liba.so is 2 , am I right ? >> > >> > >> > Right. >> > >> > And if you think you can just dlclose() it an extra time, think again. It >> > won't work. For at least two reasons. >> > >> > 1) dlopen() returns an opaque handle for each open. Opening the same .so is >> > going to give you a technically different handle, and because you can only >> > dlclose() a handle that you've opened, and you do not have a handle that was >> > used to, essentially, dlopen the directly-linked library, you can't do it. >> > >> > 2) Your existing executable has resolved the external symbols to your .so >> > already (via a process that's equivalent to dlsym(), even before your >> > executable ran). Even if you somehow manage to close it, and dlopen it back, >> > the existing linkage remains what it is. Hillarity ensues. >> >> So if I link that .so against my executable by "g++ -l " command >> ,then I can not dlclose it fully in process at all ? > > Correct. > >> >> Tp dlclose it fully , I must not link it by compiler ,but manually >> use dlopen and dlsym to resolve the external symbols . > > Correct. > >> >> But if so ,how to make the compiler not to compalain "not reference >> to symbol xxx" at compiling stage ? > > Because you did not use dlsym to resolve the external symbols. >
