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

[Julian Elischer]

On Thu, 1 May 2003, Paul Richards wrote:

> On Thu, May 01, 2003 at 09:30:32AM -0500, Jacques A. Vidrine wrote:
> > On Thu, May 01, 2003 at 03:02:55PM +0100, Paul Richards wrote:
> > > On Wed, Apr 30, 2003 at 11:41:35AM -0500, Jacques A. Vidrine wrote:
> > > > [Trimmed cc:list;  moving to freebsd-arch]
> > > > 
> > > > 
> > > > First, has something been broken by making strlcpy/strlcat into a weak
> > > > reference?
> > > 
> > > Yes, deliberately overloading it from an application now no longer
> > > works.
> > 
> > Give me a break.  Good, it should not work by accident.  An
> > application might define strlcpy for its own use, but we should NEVER
> > use the application's strlcpy. [1]
> 
> An application doesn't have any business defining a strlcpy, since
> str* is reserved.  The qpopper application is just broken and we
> shouldn't be "fixing" our libc to work around that.



Exactly..
This is why we have ports
It is also th king of thing that "configure" is supposed to fix..
The port should be altered to fix this and teh maintainers contected and
told of the problem.

I don't see why the libc needs to be changed at all.