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.
Attachment:
pgpbJa8kZWOpZ.pgp
Description: PGP signature
