This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/16881] RFE Avoid polluting user namespace with DSOs loaded by implementation.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]