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.