This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: Add tests for namespace for static linking
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 12 Nov 2014 17:32:46 +0000
- Subject: Re: RFC: Add tests for namespace for static linking
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1411080147420 dot 16602 at digraph dot polyomino dot org dot uk> <546393AA dot 9040705 at redhat 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