Re: RFC: Add tests for namespace for static linking

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 12 Nov 2014, Florian Weimer wrote:

> On 11/08/2014 02:49 AM, Joseph Myers wrote:
> > One thing we currently try to ensure manually is that glibc is
> > namespace-clean for static linking; that is, if you only use features
> > from a particular standard (including the set of features exposed by
> > headers given feature test macros such as _DEFAULT_SOURCE that don't
> > correspond to any written standard), the library objects brought in by
> > the static linker will not define or use (strong) names that are
> > reserved to the user in that standard.
> 
> Why isn't there a generic, linker-based fix which reuses the tagging we have
> for the dynamic linking case?  Because we want to keep object file boundaries?

I don't see how you envisage such a fix would work.  Making hidden_proto 
cause a call to an internal name in the static linking case would be of no 
use without also making the public names weak (whenever called in a 
problematic case) - whereas for dynamic linking it doesn't generally 
matter whether the public names are weak or strong.  And namespace issues 
still apply for dynamic linking if the call is between two shared 
libraries (or if it uses a local PLT entry, though we have the localplt 
test to try to detect and avoid those cases), it's just harder in that 
case to identify which symbol references are problems (because there is 
only an issue if calling a function in standard X in one library results 
in a function in another library, and not in standard X, being called, and 
the symbol tables of whole linked libraries don't give that information).

-- 
Joseph S. Myers
joseph@codesourcery.com