reload .so without restarting process

[net.study.sea@gmail.com]

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@courier-mta.com> 写道：

> Hatt Tom writes:
> 
>> 2013/12/3 Sam Varshavchik <mrsam@courier-mta.com>:
>> > 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.
>