`Hiding' libc symbols

[Jacques A. Vidrine]

On Thu, May 01, 2003 at 07:15:01PM +0400, Andrey A. Chernov wrote:
> On Thu, May 01, 2003 at 09:53:45 -0500, Jacques A. Vidrine wrote:
> > 
> > A libc consumer (getpwent.c):
> >     587             namesize = _strlcpy(&keybuf[1], name, sizeof(keybuf)-1);
> 
> IMHO, it is bad hack at whole, and all namespace.h tricks should be 
> removed.
> 
> The reason is quite simple. Yes, you can save libc this way, but what
> happens, if application linked, say, with libc AND libncurses (insert any
> other system library here)? libc will be saved, but libncurses will not.  
> It means, to be logically, you need to replace strlcpy with _strlcpy in
> ALL FreeBSD libraries. Better way is stop doing half-singing - 
> half-dancing and produce linker error when application attempts to replace 
> any function in standard namespace. It automatically makes impossible 
> broken binary-only packages.
> 
> So, I vote for namespace.h removing (i.e. all _ tricks). Who with me?

I'm with you ... as long as:


  (a) We then post-process libraries (or object files) to
      automagically handle the symbols (all of them, or maybe just
      those not covered by some standard we pick in the case of libc).
      e.g. something such as
         objcopy --weaken ${.IMPSRC} ${.TARGET}
      but a bit more work.


  (b) We give Daniel and others working on threaded libraries a chance
      to discuss the special needs there.  (That _is_ why namespace.h
      was originally created.  We do need to handle stubs somehow; weak
      symbols alone are not enough.)


  (c) We do it after 5.1-RELEASE, and before 5.2-RELEASE;  or we only
      do it in 6.x.


  (d) I don't have to do it all.


Cheers,
-- 
Jacques Vidrine   . NTT/Verio SME      . FreeBSD UNIX       . Heimdal
nectar at celabo.org . jvidrine at verio.net . nectar at freebsd.org . nectar at kth.se