Re: how to NOT export symbols in statically linked 3rd party shared libs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thank you Andrew!

That helps - a lot!!

Chris

Andrew Haley schrieb:
> Chris Miller wrote:
>   
>> Thank you, Andrew,
>>
>> actually, I figured that out after I sent this question to the ML.
>> However, the next question, which seems to be the core of the problem
>> arises:
>> What I really want to make sure is that at runtime, local symbols (the
>> ones not exported) will have precedence over exported (colliding)
>> symbols of other libs.
>>
>> Is that the case?
>>     
>
> If and only if you use -Bsymbolic when linking, yes.  However,
> -Bsymbolic is not without problems: one of the guarantees of C is that
> &symbol always returns the same result, no matter who is asking.  All
> manner of things can break if this isn't true.
>
> Also, if you use -Bsymbolic in a shared library you also should link
> all executables with -fPIC.  This is needed because -Bsymbolic breaks
> copy relocations in an executable so that it ends up with a private
> copy of all the statically-allocated data in shared libraries.  All
> hell then breaks loose, as you can imagine.  :-)  Compiling the
> executable -fPIC ensures that there are no copy relocs created.
>
> Andrew.
>
>   


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux