`Hiding' libc symbols (was Re: cvs commit: src/lib/libc/gen ...)

[Andrey A. Chernov]

On Thu, May 01, 2003 at 11:51:15 -0400, Daniel Eischen wrote:
> > Threads is completely another issue. We can do ANY tricks threads needs
> > when it is NOT affects normal linking (under "normal" I mean preventing
> > standard namespace replacement from outside of libc). If current
> > replacement way for threads not allows preventing, it should be changed
> > somehow to be truely libc internal, i.e. not explotable from outside of
> > libc/libc_r/other threads libs.
> 
> I'm not sure what you mean, but what we have works well.  There
> may be times that we want to call the internal _foo() and other
> times were we want to call foo().  How are you going to build
> a tool that can tell the difference if you reference foo() in both
> places?

Internal _names are the way threads tricks are implemented. I am looking
from outside of that scheme, so this details are not needed. From outside
of this scheme now I can replace, say, open() with anything I want
(because it is _ tricked in threads). It should not happens. I.e. open()  
replacement in threads should happens, but in linked application - not. It
means libc and libc_r must share some unusual replacement way which
application never can normally use.