This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16881] RFE Avoid polluting user namespace with DSOs loaded by implementation.
- From: "carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 29 Apr 2014 20:43:38 +0000
- Subject: [Bug libc/16881] RFE Avoid polluting user namespace with DSOs loaded by implementation.
- Auto-submitted: auto-generated
- References: <bug-16881-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16881
Carlos O'Donell <carlos at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos at redhat dot com
Summary|gethostbyname and resolver |RFE Avoid polluting user
|namespace conflict |namespace with DSOs loaded
| |by implementation.
--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
Florian Weimer and I had a dicussion about this last year. In the general case
there is no other option except to track and enforce the global namespace of
all libraries and exported symbols for the entire distribution and avoid
overlap. Note that LSB does some of this by standardizing the exported symbol
lists. Florian had a database that he constructed to test for these kinds of
things.
The discussion ends here where we both agree that no amount of tooling will fix
this, but the tooling will help mitigate the problems:
https://sourceware.org/ml/libc-help/2013-12/msg00010.html
There may be some amount of dlmopen() usage that we can do to ensure the
implementation loaded modules are hidden from the user modules, but eventually
the breakage will happen and the only solution is to alter the linkage scope
(drawing a wall around things) or fix the symbols.
Does that make sense?
Retitled to reflect RFE nature.
--
You are receiving this mail because:
You are on the CC list for the bug.